Re: Deprecations vs. backwards-incompatible changes for tightening behavior that hides probable developer error

Hello, the select_related change was a really good one, after updating I found around 3 or 4 queries that had a typo in select_related which was obviously never noticed before. In this project finding those errors was not complicated at all, but I believe that on a big project that also has

Re: [Question] MySQL Microseconds stripping

I think a simple setting allowing to use the old behaviour should be enough, shouldn't it? How does it handle other db backends? I'm not sure if oracle has an option for datetime precision, but if it does, it makes sense to have a global setting for datetime precision, as right now you are

Re: Deprecations vs. backwards-incompatible changes for tightening behavior that hides probable developer error

On Monday 21 December 2015 20:45:26 Carl Meyer wrote: > > Obviously the first question is whether the behavior in question is > documented. If it is, then a deprecation path is definitely required. On > the other hand, if the current behavior contradicts the documentation, > then it's a bug and

Re: FK constraints are not checked at the end of nested atomic blocks

On Monday 21 December 2015 19:42:22 Anssi Kääriäinen wrote: > The only generic way to check the constraints is to run through all > tables and their constraints. The constraint check itself is a check > that a matching row in a foreign table exists for each row of the > checked table. This means

Re: [Question] MySQL Microseconds stripping

I think this is a fairly big oversight that should be fixed in the most backwards compatible way, so users don't need to change their code, or only have to change it minimally. I'm with Aymeric here. Does Django have visibility of the field constraints at insert/select queryset time? Ideally

Re: A community Poll

> > I'm quite sure I was driven to that PR because importing ContentTypes > was causing lots of pain with AppState not being ready. > Whenever I see this error message pop up, it's not because code directly imports ContentTypes, but because it imports some other models.py module, which in

Re: 1.8 shipping invalid .py files in the startapp template

FWIW, this also bit me. I have a deploy script that runs python -m compileall as part of its build process. It was pretty easy to work around by adding -x app_template, but why make everyone else work around Django? ISTM it would be better to call the files .py_template instead since they

Re: Deprecations vs. backwards-incompatible changes for tightening behavior that hides probable developer error

Hi Tim, On 12/21/2015 08:09 AM, Tim Graham wrote: > I'd like to ask for opinions about whether or not deprecations are more > useful than making small backwards incompatible changes when they move > Django in a direction toward unhiding probable developer error. > > An example from a past

Re: A community Poll

Hi Curtis, On 12/21/2015 06:52 AM, Curtis wrote: > Whilst I'm awake... a pull request I made to a 3rd party project > included replacing explicit model imports for relation fields with lazy > binding -- ForeignKey('contenttypes.ContentType') in this case. > > The author pointed out this didn't

Re: FK constraints are not checked at the end of nested atomic blocks

The only generic way to check the constraints is to run through all tables and their constraints. The constraint check itself is a check that a matching row in a foreign table exists for each row of the checked table. This means that the check could take hours on large databases. In addition the

Re: Add "view_decorators" to django.views.generic.View

Could you summarize the pros and cons of this new technique versus the existing @method_decorator() recommendation [1]? Does it duplicate all the functionality provided by method_decorator such that we would no longer recommend that technique in the class-based view docs? [1]

Re: Add "view_decorators" to django.views.generic.View

I would find that useful. In my experience, I often have a mixture of CBV and non-CBV code, and it's annoying to shoehorn decorators into the as_view method. It would be much more convenient to just add to self.view_decorators. -- You received this message because you are subscribed to the

Help needed with the MySQL max index length problem for Django 1.10

I merged the often requested increase of User.username max_length to 254 characters [1] a few weeks ago, however, the ticket was reopened pointing out this issue: "This patch breaks on MySQL installations using the utf8mb4 charset, because it breaks the index length limit - it comes out at a

Re: CBV contrib.sitemaps

On Tuesday, December 15, 2015 at 6:35:06 PM UTC-5, Shai Berger wrote: > > Hi Carl, > > On Tuesday 15 December 2015 18:17:36 Carl Johnson wrote: > > I was adding a sitemap to a project, and I more or less had to rewrite > the > > views from scratch because sitemap expects to receive a

Deprecations vs. backwards-incompatible changes for tightening behavior that hides probable developer error

I'd like to ask for opinions about whether or not deprecations are more useful than making small backwards incompatible changes when they move Django in a direction toward unhiding probable developer error. An example from a past release is the validation of fields in select_related() [1].

Re: FK constraints are not checked at the end of nested atomic blocks

While expensive operations may be unsuitable for general consumption, this kind of validation may be useful in special cases and offline jobs, notably in "data" migrations. So I think we should consider supporting them via an argument to atomic(). Be that as it may, so long as we do not plan

Re: A community Poll

Hello Curtis, 2015-12-21 14:52 GMT+01:00 Curtis : > So aside from the obvious "preventing circular imports", what other > benefits do people see? > I'm afraid this is an example of "worse is better". String references to other models in FK definitions are one of the

A community Poll

Whilst I'm awake... a pull request I made to a 3rd party project included replacing explicit model imports for relation fields with lazy binding -- ForeignKey('contenttypes.ContentType') in this case. The author pointed out this didn't play well with their IDEs refactoring tool, and asked if

Add "view_decorators" to django.views.generic.View

Hey all, Tim wanted me to open some discussion on this idea: https://github.com/django/django/pull/5637/files Essentially, it allows you to add an explicit list of decorators for a View to apply to its view function when someone calls as_view. This allows the View author to dictate which

Re: FK constraints are not checked at the end of nested atomic blocks

2015-12-21 13:12 GMT+01:00 Anssi Kääriäinen : > The check_constraints operation is extremely expensive, and not suitable > for use at the end of savepoints. Ah. Too bad! -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django

Re: FK constraints are not checked at the end of nested atomic blocks

Hello, When a question of "should Django do A or B here?" comes up, adding a setting to let the user choose is the last resort, because it's really a cop-out, not the default choice. Django explicitly creates FKs on PostgreSQL as DEFERRABLE INITIALLY DEFERRED in order not to check constraints

Re: FK constraints are not checked at the end of nested atomic blocks

The check_constraints operation is extremely expensive, and not suitable for use at the end of savepoints. The reason why we use deferred constraints by default is mostly historical. We do need deferred constraints for fixture loading, and applications might rely on current implementation, but we

Re: MOSS Award to Django

On Mon, Dec 21, 2015 at 6:05 AM, Samuel Bishop wrote: > Hi Andrew, > > Thanks for the detailed response. I'm glad to hear you have tried a few > different ways to implement this, and having read through your reply, and > the channels docs again, I have more questions :-) >

FK constraints are not checked at the end of nested atomic blocks

I opened this ticket https://code.djangoproject.com/ticket/25955 The last proposal for the improvement https://code.djangoproject.com/ticket/25955#comment:5 add parameter in OPTIONS DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', # ...

Re: [Question] MySQL Microseconds stripping

2015-12-20 22:57 GMT+01:00 Cristiano Coelho : > Thanks for the suggestion, I think that work around might just add too > much code, so I'm probably going the way of converting every datetime > column of every table to datetime(6) and afford the extra storage (and >