Re: Fate of sql* management commands

Hello, sorry for the delay (I'm moving home), thanks for the detailed explanations, I've learned a lot about the new status of migrations, and I guess every django users might benefit from this "shift of canonical representation", that's why there shouldbe room for a proper introduction in django

Re: Fate of sql* management commands

2015-04-02 23:03 GMT+02:00 Marc Tamlyn : > As far as I'm aware, we have some code paths which still work in 1.9 which > generate tables directly from the models. We use this when running Django's > own test suite, and it is also used now by djangobench. I haven't looked > into exactly how to turn

Re: [ANNOUNCE] Django 1.8 released

On Wed, Apr 1, 2015 at 10:46 PM, Tim Graham wrote: > Django 1.8, the next long-term support release, is now available: > > https://www.djangoproject.com/weblog/2015/apr/01/release-18-final/ > > With the release of Django 1.8, Django 1.6 has reached end-of-life. As > such, Django 1.6.11 is the fin

DKIM signing option for stmp.MailBackend?

Hi all, Is anyone using DKIM signing for densing emails? Does it make sense to you to have a feature like that in Django core or is this typically something that should be in it's own app? We use it to sign our emails so the don't end up in spam boxes. It could be part of smtp mail backend. Ch

Re: Fate of sql* management commands

On 04/03/2015 03:17 AM, Aymeric Augustin wrote: > 2015-04-02 23:03 GMT+02:00 Marc Tamlyn >: > > As far as I'm aware, we have some code paths which still work in 1.9 > which generate tables directly from the models. We use this when > running Django's own

Re: Fate of sql* management commands

> > > > > An alternative would be to ignore migrations files, regenerate a fresh > > set of migrations, and dump the corresponding SQL. > > I think this approach would be much preferable to using the totally > separate legacy code path. Presented as a tool for debugging migrations > issues, and wit

Re: Fate of sql* management commands

And the auto-generated in-memory migrations should work for tests too, right? On Friday, April 3, 2015 at 2:34:23 PM UTC-4, Andrew Godwin wrote: > > > >> > An alternative would be to ignore migrations files, regenerate a fresh >> > set of migrations, and dump the corresponding SQL. >> >> I think

Re: Fate of sql* management commands

On 04/03/2015 02:30 PM, Collin Anderson wrote: > And the auto-generated in-memory migrations should work for tests too, > right? Well, that would depend on whether you have anything important in a RunSQL migration, or otherwise in a migration but not reflected in your model files. So, maybe. But i

Re: ModelManager behaviour for Proxy Models

Hi Mahmud, I personally really like the technique of having a "type" column in the base model. It allows you to query across all types but still get the correct subclass. However, I think the manager is a good place to handle this. You could have a manager that looks something like: objects =

Re: DKIM signing option for stmp.MailBackend?

On Sat, Apr 4, 2015 at 12:24 AM, Loek van Gent wrote: > Hi all, > > Is anyone using DKIM signing for densing emails? Does it make sense to you > to have a feature like that in Django core or is this typically something > that should be in it's own app? > We use it to sign our emails so the don't