Right, my bad.
So itt looks like we h ave week_day which has sunday = 1, while ISO week
days have monday = 1. What other "peculiar and unintuitive" behaviour is
there Anatol?
On Wed, 25 Sep 2019 at 15:39, Mariusz Felisiak
wrote:
> In this ticket we mentioned *iso_week* not *iso_week_day*. *wee
On Thu, Sep 26, 2019 at 11:33 AM Adam Johnson wrote:
> Right, my bad.
>
> So itt looks like we h ave week_day which has sunday = 1, while ISO week
> days have monday = 1. What other "peculiar and unintuitive" behaviour is
> there Anatol?
>
it's just that. Django's docs say it themselves (emphas
I think you can reopen the ticket and make a pull request!
On Thu, 26 Sep 2019 at 00:55, Sky Christensen
wrote:
> It seems that so far two people have replied in favour of re-opening
> this ticket (or maybe make that three people if you count me), and none
> have replied against re-opening it.
>
one last thing preventing me from submitting the PR is that the
implementation is database specific and while I'm reasonably sure my oracle
implementation is correct, I don't have an easy means of testing it. What's
the team's go-to approach here?
Cheers
Anatol
On Wed, Sep 25, 2019 at 2:10 PM Ana
nevermind, found official dockerfiles for XE, will try those
On Thu, Sep 26, 2019 at 12:58 PM Anatol Ulrich
wrote:
> one last thing preventing me from submitting the PR is that the
> implementation is database specific and while I'm reasonably sure my oracle
> implementation is correct, I don't
Given the following example model:
class M1(models.Model):
m2_set = models.ManyToManyField('M2')
It is already possible to associate *one* M1 with *many* M2s with a single
DB query:
m1.m2_set.add(*m2s)
However it's more difficult to associate *many* M1s with *many* M2s,
particularly if yo
Errata: The proposed default value for assert_no_collisions is False rather
than True, for safety.
On Thursday, September 26, 2019 at 10:45:45 AM UTC-7, David Foster wrote:
>
> Given the following example model:
>
> class M1(models.Model):
> m2_set = models.ManyToManyField('M2')
>
> It is alr
Hello all,
I was looking into ticket 15610 (https://code.djangoproject.com/ticket/15610),
which describes an issue where generic foreign keys fail when the
content-type table is located in a separate database from the tables
containing the generic relations.
The ticket makes this assumption "T
Hi,
I am playing around at the DjangoCon US 2019 Sprints and while trying to do
my share one thing stands out in the open tickets is: Some are very old and
others have not been touched in a while.
I did a simple analysis of accepted and open tickets based on last modified
time (kind of a live
Thanks Adam. I wasn't sure if I needed to wait for a core developer to
re-open the ticket.
I just re-opened it then and I'll get onto writing a patch soon.
On 2019-09-26 20:58, Adam Johnson wrote:
I think you can reopen the ticket and make a pull request!
On Thu, 26 Sep 2019 at 00:55, Sky Ch
I have seen other open source project handling that with a comment saying
the ticket will be closed in a short time. I assume closing with a comment
it's fine to reopen if it's still relevant would be fine. Maybe also
tagging the tickets with a label "closed as stalled" ?
On Fri, Sep 27, 2019, 01:
11 matches
Mail list logo
