Re: unique_together does not work as expected with nullable fields

[Rich Rauenzahn]

On Friday, April 29, 2016 at 11:00:37 AM UTC-7, Aymeric Augustin wrote:
>
> Hi Rich,
>
> On 29 Apr 2016, at 19:52, Rich Rauenzahn > 
> wrote:
>
>
> I see now that I need to provide a sentinel value -- 
> BOO=True,VAL=, or manually create additional unique indexes.
>
>
> Indeed, you should write a migration with a RunSQL operation that creates 
> a unique index on boo where boo = true. Then you can have only one row with 
> boo = True.
>
 

It sounds like my request should probably be appended to this ticket, then: 
 https://code.djangoproject.com/ticket/11964 (Add the ability to use 
database-level CHECK CONSTRAINTS)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7bfd2862-72bc-4df7-bded-a9513fe009b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Table Locks and bulk creating inherited models

[Geoffrey Martin-Noble]

Is there a particular reason Django doesn't implement table locks? These 
are vendor-specific, but seem to be common to various SQL backends, which 
is something Django generally does well.

I am working on an application in which I would like to be able to perform 
bulk create on inherited models. I see the issue with not being able to 
fetch primary keys, but it seems that this could be accomplished by placing 
a table lock on both the parent and inherited table, determining the 
appropriate primary keys in python, circumventing a table autoincrement, 
and then bulk creating both models.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8446a5fe-3cfb-4efa-bb40-84e70dd234de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Change executed raw mysql queries to return timezone aware datetimes.

[Bryce Drennan]

Would a per-database setting "TZ_AWARE_DATETIMES" help address the 
backwards compatability issue? It would default to True but would allow 
those who find the migration painful to do that on their own schedule.

On Friday, April 29, 2016 at 2:06:34 AM UTC-7, Anssi Kääriäinen wrote:
>
> I'm mildly in favor of b), seems like most projects would want that 
> anyways. 
>
> If there is a really easy way for picking tz conversions per cursor, 
> then that could be a good approach, too. Something like cursor = 
> connection.cursor(convert_tz=True) might work. I know then MySQL would 
> have a bit different API than the rest of the backends for cursor 
> creation, but the SQL executed is going to be backend specific in any 
> case... 
>
>  - Anssi 
>
> On Fri, Apr 29, 2016 at 10:16 AM, Aymeric Augustin 
> > wrote: 
> > Hello Bryce, 
> > 
> > Oops! I didn’t realize that conversions were a parameter of the database 
> > connection on MySQL :-( So, yes, it is technically possible to implement 
> the 
> > solution you’re describing. 
> > 
> > However I’m not positive that we should make this change. There’s an 
> > argument to be made that database settings should only affect the ORM 
> and 
> > other Django components. 
> > 
> > `from django.db import connection; connection.cursor()` is supposed to 
> give 
> > you a database cursor using the credentials from your settings file, but 
> > apart from that, it’s just a regular database cursor.  Django’s wrapper 
> is 
> > expected to be transparent. I believe it’s important, as much as is 
> > practical, to preserve the ability to interact with the database without 
> > interference from Django. 
> > 
> > Also reverting backwards-incompatible changes in the following release 
> is 
> > painful for users… Even if the first backwards-incompatible change is a 
> sunk 
> > cost at this point, reverting it would be particularly vexing for 
> affected 
> > users who updated their code. 
> > 
> > To sum up, the question we’re reaching is: 
> > 
> > “When USE_TZ =True, should cursor.execute() with a Django cursor return 
> (a) 
> > naive datetimes like a plain MySQLdb cursor (b) aware datetimes in UTC 
> like 
> > the Django ORM?" 
> > 
> > Who has an opinion on this question? 
> > 
> > Best regards, 
> > 
> > -- 
> > Aymeric. 
> > 
> > On 29 Apr 2016, at 00:48, Bryce Drennan  > wrote: 
> > 
> > I'm wondering if we're using the term "global" slightly differently. 
> > 
> > Yes, prior to the changes removing converters, Django had these 
> converters 
> > globally applied to all mysql connections that it created. However, they 
> > didn't apply to mysql connections created outside of django, nor did 
> django 
> > have to implement the converters globally like it did. Timezone support 
> > could be implemented at the connection level instead of globally being 
> > applied to all mysql connections. 
> > 
> > I have made this proof of concept to illustrate two distinct mysql 
> > connections, one which adds the timezone conversion, and one which does 
> not: 
> > 
> https://gist.github.com/brycedrennan/fc5f1cb08afe6dba034e3185368a7e2a/revisions
>  
> > 
> > It seems reasonable to me that connections created by Django would have 
> > Django specific functionality (like returning timezone aware datetimes). 
>  If 
> > a specific DB should not have this functionality then we could setup the 
> > converter to not be applied to those connections.  If specific 
> non-django 
> > code requires naive datetimes then it can use a non-django db 
> connection. 
> > Does that make sense? I am not super familiar with the django codebase 
> so I 
> > worry I'm missing something. 
> > 
> > 
> > On Monday, April 25, 2016 at 2:40:42 PM UTC-7, Aymeric Augustin wrote: 
> >> 
> >> Hi Bryce, 
> >> 
> >> #19738 is unrelated to the problem you’re describing. It was fixed in 
> >> d9521f66 which removed adapters i.e. transformations of parameters 
> passed to 
> >> the database. 
> >> 
> >> You’re talking about the removal of converters i.e. transformations of 
> >> values returned by the database. It is discussed in #23820 and was 
> committed 
> >> in ec186572. 
> >> 
> >> When I implemented time zone support in Django 1.4, conversion of 
> values 
> >> could happen in several places. This was improved in Django 1.8 with 
> >> e9103402. 
> >> 
> >> This unified approach to conversions allowed to expand the 
> functionality 
> >> of the ORM which now tracks the type of returned values, even computed 
> ones. 
> >> 
> >> That said, this design cannot work well for raw queries because Django 
> >> doesn’t know the type of returned values, so it cannot apply a suitable 
> >> converter. You get whatever the DB-API module gives you. In a sense, 
> this 
> >> behavior is sensible: Django shouldn’t interfere with values provided 
> by raw 
> >> queries. 
> >> 
> >> This is where I introduced the backwards incompatibility you’re talking 
> >> about: 
> >> 
> >> 
> https://github.com/django/django/commit/ec1865

[ANNOUNCE] Django bugfix releases issued: 1.9.6 and 1.8.13

[Tim Graham]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2016/may/02/bugfix-releases/


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/01722d4b-b75d-424e-b744-242ba854395b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Table Locks and bulk creating inherited models

[Russell Keith-Magee]

Hi Geoffrey

On Tue, May 3, 2016 at 3:42 AM, Geoffrey Martin-Noble  wrote:

> Is there a particular reason Django doesn't implement table locks? These
> are vendor-specific, but seem to be common to various SQL backends, which
> is something Django generally does well.
>

I’m not aware of any philosophical or technical reason why they haven’t
been implemented - as far as I’m aware, it’s simply a matter of nobody has
asked for them, and nobody has offered a patch for them.

Over the last few years, we’ve been moving away from the Lowest Common
Denominator model for the database backends, and towards a general
philosophy of “if a database can do it, we will support it”. The only
restriction on that is finding an elegant way to express the underlying
idea in a way that can be opt-in, and is consistent with existing APIs.

Have you given any thought to what the API for a table lock would look like?

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq8486t6cuaivxj6iLoXtUJ1UaNH%2BvyUmNEPeYf1SFO%2B2oWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Table Locks and bulk creating inherited models

[Curtis Maloney]

On 03/05/16 09:47, Russell Keith-Magee wrote:

Hi Geoffrey

Have you given any thought to what the API for a table lock would look like?


Since it's a table-wide action, having it on the Manager makes some 
sense... though it would be, I suspect, implemented via _meta.


I can see something like:

with MyModel.objects.lock():
... do stuff ...

Being an intuitive, inoffensive and hookable API.

--
Curtis

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5727E7A3.8090100%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Table Locks and bulk creating inherited models

[Gavin Wahl]

> with MyModel.objects.lock():
> ... do stuff ... 

This is misleading as it implies the lock is released when the context 
manager exists, but in postgres at least the lock will be held until the 
end of the transaction.

What advantage does implementing an ORM API for table locking have over 
`cursor.execute("LOCK TABLE mymodel")`?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0fdb1d35-3a08-4095-a40e-0aaed462f6dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Table Locks and bulk creating inherited models

[Curtis Maloney]

On 03/05/16 14:08, Gavin Wahl wrote:

 > with MyModel.objects.lock():
 > ... do stuff ...

This is misleading as it implies the lock is released when the context
manager exists, but in postgres at least the lock will be held until the
end of the transaction.


Hah!  Shows how much I know about table locking :P


What advantage does implementing an ORM API for table locking have over
`cursor.execute("LOCK TABLE mymodel")`?


Much the same as the rest of the ORM API : Abstraction and convenience.

Even if it's just so you can pass a ModelClass instead of having to know 
the table name... and avoid having to access cursor directly.


Perhaps transaction.lock_table(model) since, as you say, it's related to 
the term of the transaction?


--
Curtis

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/57282559.2080408%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Table Locks and bulk creating inherited models

[Gavin Wahl]

I don't think any abstraction is possible. Postgres has 8 different
table-level locking modes, in addition to advisory locks and 4 row-level
lock modes. I would say any attempt to abstract that would remove
functionality, and that would not be convenient.

We are already suffering from an over-abstraction of locking -- we have
limited support for SELECT ... FOR UPDATE, but not SELECT ... FOR SHARE
(not to mention FOR NO KEY UPDATE and FOR KEY SHARE, which to be honest
probably aren't useful to call from an ORM). QuerySet.select_for_update has
an option to enable NO WAIT, but not SKIP LOCKED.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACPudh0KQ4XW-2G71ZDx__g6AmUO5v6QDF7zWPdCAj_1Gnjeag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.