Improving aggregate support (#14030)

I'm interested in tackling ticket#14030, ideally before the Jan 20th cutoff, but I'm looking for some guidance. There have been a lot of references to Anssi Kääriäinen attempting an ORM refactor before trying to fix aggregates, but I'm not sure if

Re: South data-migration and custom save() method

Yep, this is what I currently do and I was just hoping for a cleaner solution in 1.7. That's all. Thanks for django.db.migrations Andrew. Val On Fri, Dec 20, 2013 at 11:41 AM, Andrew Godwin wrote: > This will also be true for django.db.migrations; there's no way we can

Re: South data-migration and custom save() method

This will also be true for django.db.migrations; there's no way we can serialise save methods as part of the model for later use in migrations. If you want to use complex save logic in migrations, you'll have to copy it into the migration file (which also means the migration will keep working as

South data-migration and custom save() method

South (latest) has a limitation where it ignores a custom save() method in the model class. I am wondering if that is going to be true for the new South in the core in Django 1.7? Thanks, Val -- You received this message because you are subscribed to the Google Groups "Django developers"

App-loading reloaded - custom app names in the admin

Merge request I sent a pull request implementing my second goal: https://github.com/django/django/pull/2089. It allows customizing application names in the admin. A handful of core developers were kind enough to oversee my efforts. Their feedback on the design has been positive. However, as

Re: Problem with number format when not using L10N

In conclusion one could say that if USE_L10N is not True then no thousands separator is displayed, of course, only thru the configuration of django. El viernes, 20 de diciembre de 2013 08:15:58 UTC-5, Yonel Ceruto González escribió: > > Ok no problem, > > Although the documentation may be

Re: Problem with number format when not using L10N

Ok no problem, Although the documentation may be inconsistent, I think the comment https://code.djangoproject.com/ticket/21544 # comment: 8, discloses a particular case where I customize the THOUSAND_SEPARATOR with USE_L10N = False. This is the source of my problem, because he expects to see

Re: SchemaEditor Enhancements

Russ is right, it's still open for changes, though I want to oversee any changes very carefully because I want to make sure we ship something that makes sense overall! Altering column names is done as part of alter_field (if you look through that huge method, you'll see it somewhere in there);