On Saturday, January 9, 2016 at 7:01:38 AM UTC+2, Curtis Maloney wrote:
>
> Hey all,
>
> I'm trying to write a PR for adding Postgres9.4's "FILTER" syntax for
> aggregates, but I've hit a bug I can't figure how to fix [and nobody's
> awake on IRC :)]
>
> https://github.com/django/django/pull/59
On Sun, Jan 10, 2016 at 5:22 PM, Sean Brant wrote:
> I've always considered this a bug waiting to happen. I have seen many errors
> with the get operation failing because it returned more then one value.
> Usually you don't notice the error until you hit production. I always
> suggest the lookup
On Sun, Jan 10, 2016 at 11:10 AM, Florian Apolloner
wrote:
> On Sunday, January 10, 2016 at 9:09:37 AM UTC+1, Anssi Kääriäinen wrote:
>>
>> The save() operation matches the semantics of upsert exactly - maybe we
>> could use upsert there?
>
> Not sure .save() would be a good candidate for that. In
On Fri, 8 Jan 2016 11:38:04 -0700
Carl Meyer wrote:
> Thanks everyone for the reviews. I've pushed a new commit addressing
> most of the issues raised:
> https://github.com/django/deps/commit/62b0ee351727cb0e7ef41ba6dd2f3f7280a219de
>
> More comments and replies (to various people in the thread)
On Sunday 10 January 2016 08:09:33 Carl Meyer wrote:
> On 01/09/2016 09:29 AM, Shai Berger wrote:
> > There are two kinds of data migrations, generally speaking.
> >
> > [...]
> >
> > The other is migrations which *create* data -- fill in tables for
> > database- implemented-enums, for example. If
Hi,
On Saturday 09 January 2016 18:29:32 Shai Berger wrote:
> The other is migrations which *create* data -- fill in tables for
> database- implemented-enums, for example. If you remove these, you are
> going to break your tests (if you do this and haven't broken your tests,
> your tests are missi
> On Jan 10, 2016, at 2:09 AM, Anssi Kääriäinen wrote:
>
> If I recall correctly, MySQL doesn't offer a way to specify on which index
> you want to do the conflict resolution. This leads to problems - the upsert
> might affect the wrong row if there are multiple unique indexes on the table.
>
Hi James,
> Generic Foreign Keys is pretty useful, do you think Django could provide a
> model with 2 GFKs and Generic Many-to-Many fields ?
>
> There is a little old implementation in an app that has been out there for a
> while so it's pretty old: https://github.com/coleifer/django-generic-m2m
Hi all,
Generic Foreign Keys is pretty useful, do you think Django could provide a
model with 2 GFKs and Generic Many-to-Many fields ?
There is a little old implementation in an app that has been out there for
a while so it's pretty old: https://github.com/coleifer/django-generic-m2m/
We could p
On Sunday, January 10, 2016 at 9:09:37 AM UTC+1, Anssi Kääriäinen wrote:
>
> The save() operation matches the semantics of upsert exactly - maybe we
> could use upsert there?
>
Not sure *.save()* would be a good candidate for that. In the best case,
*.save()* should execute one INSERT or UPDAT
If I recall correctly, MySQL doesn't offer a way to specify on which index
you want to do the conflict resolution. This leads to problems - the upsert
might affect the wrong row if there are multiple unique indexes on the
table.
PostgreSQL's version of upsert has a problem, too. It doesn't offer a
11 matches
Mail list logo
