Re: Proposal for prepared statements API

On 26 March 2014 10:10, Florian Apolloner wrote: > On Tuesday, March 25, 2014 11:57:51 PM UTC+1, Curtis Maloney wrote: >> >> Firstly -- can we assume anyone using this feature is not a complete >> novice, and so will take the caveats mentioned into consideration? >> > >

Re: Migrations in Django 1.7 make unit testing models harder

On Tue, Mar 25, 2014 at 4:02 PM, Florian Apolloner wrote: > On Tuesday, March 25, 2014 9:12:42 PM UTC+1, Andrew Godwin wrote: >> >> So, the functionality whereby you can have apps which do not use >> migrations (i.e. that use the old creation backends) is meant to go away

Re: Add support for get_or_none?

On Thu, Mar 20, 2014 at 9:31 PM, Florian Apolloner wrote: > On Thursday, March 20, 2014 2:01:25 PM UTC+1, Cal Leeming [Simplicity > Media Ltd] wrote: >> >> I'll give it a couple more days for a BDFL to gives the thumbs up/down. >> > > Well, we don't have BDFLs anymore and

Re: Proposal for prepared statements API

On Tuesday, March 25, 2014 11:57:51 PM UTC+1, Curtis Maloney wrote: > > Firstly -- can we assume anyone using this feature is not a complete > novice, and so will take the caveats mentioned into consideration? > Yes > Yes, prepared statements are local to their connection/session. And would

Re: Migrations in Django 1.7 make unit testing models harder

On Tuesday, March 25, 2014 9:12:42 PM UTC+1, Andrew Godwin wrote: > > So, the functionality whereby you can have apps which do not use > migrations (i.e. that use the old creation backends) is meant to go away in > 1.9. > Uhm, strong -1 here unless you have really convincing arguments, I really

Re: Proposal for prepared statements API

Firstly, I mostly proposed this API in response to others calls for it. Yes, I'd love to have it, but I'm content to leave it in the "too hard" basket. That said, it doesn't mean I'm not going to try to solve these issue :) So: Firstly -- can we assume anyone using this feature is not a

Re: Migrations in Django 1.7 make unit testing models harder

I'll update the deprecation document to include more direct information about DatabaseCreation and the legacy app sync method. I'm not sure "TDD is a bit harder" is a release blocker - the TDD I do generally doesn't have that much model creation, and it's relatively easy to just run

Re: Migrations in Django 1.7 make unit testing models harder

I don't see any meaningful notes about apps being required to ship migrations beginning with 1.9. I do see deprecation notes about the syncdb signals changing and the syncdb command itself is clearly deprecated. This legacy behavior is handled by sync_apps in the migrate command but there

Re: Migrations in Django 1.7 make unit testing models harder

I just read the deprecation timeline and the very brief mention of syncdb command and signals going away doesn't really seem to sufficiently detail the "side-effects" you mention. Anyone who hasn't read your email is going to be unpleasantly surprised. I also don't see any deprecation warnings in

urls in {% blocktrans %} fails silently.

Hi all! Currently, for adding an url to a blocktrans, we need: {% url "home" as home %} {% blocktrans with the_url=home %} ... {% endblocktrans %} (https://docs.djangoproject.com/en/dev/topics/i18n/translation/#blocktrans-template-tag) However, this is not equivalent to use {% url "home" %}

Re: Migrations in Django 1.7 make unit testing models harder

So, the functionality whereby you can have apps which do not use migrations (i.e. that use the old creation backends) is meant to go away in 1.9 (i.e. the standard three-release deprecation cycle). Most of the side-effects of this are detailed in

Re: Proposal for prepared statements API

On IRC, @apollo13 asked some very good questions about the lifecycle of prepared statements. I would like to elaborate. Prepared statements usually live on the server, in the context of a session -- which, for Django, means they're only valid in the thread where they were built; without

Re: Migrations in Django 1.7 make unit testing models harder

Andrew, Can you clarify exactly what is deprecated in this work-around? I don't see anything in the deprecation timeline to remove MIGRATION_MODULES nor any pending deprecations related to its usage. It seems like could probably be replaced by something that uses the app-loading/app-configs

Re: Migrations in Django 1.7 make unit testing models harder

On Tuesday, March 25, 2014 7:14:55 PM UTC+1, Andrew Godwin wrote: > > Yes, the new behaviour is by design, in the sense that the workaround you > mentioned will be deprecated in 1.9 (along with all syncdb-related > functionality). > What exactly will get deprecated here? -- You received this

Re: Migrations in Django 1.7 make unit testing models harder

Do we have an equivalent of south's --update? This would mean you don't get many files. We don't want to make it too hard for people to work in a strict TDD fashion. M On 25 Mar 2014 18:15, "Andrew Godwin" wrote: > Yes, the new behaviour is by design, in the sense that the

Re: Migrations in Django 1.7 make unit testing models harder

Yes, the new behaviour is by design, in the sense that the workaround you mentioned will be deprecated in 1.9 (along with all syncdb-related functionality). This way, tests always run against the version of your models that production would run, so you don't run the risk of the tests passing

Migrations in Django 1.7 make unit testing models harder

Hi Django devs, I've just started a new project in 1.7b, and the development experience working with unit tests on models is more complicated than it was in 1.6. It's all down to how the throwaway test databases are created. In 1.6, the create_test_db function "Creates a new test database and

Re: Proposal for prepared statements API

On the None -> IS NULL issue, I presume there are, for any given use case, not that many argument permutations of None and not None passed. I suggest that the PreparedStatement abstraction map to multiple actual prepared statements, one for each None/not None permutation. Then when executing,

Re: Proposal for prepared statements API

Is falling back to a direct queries being considered? Not all backends support prepared statements or recommend using them. The native mssql drivers support prepared statements, but the other drivers django-mssql supports do not. Also, "In SQL Server, the prepare/execute model has no significant

Re: Proposal for prepared statements API

On Tuesday, March 25, 2014 2:53:42 PM UTC+2, Curtis Maloney wrote: > > ps = MyModel.objects.filter(foo__lt=Param('a').prepare() > > The result is now a callable that accepts one parameter - "a". To invoke > the query: > > results = ps(a=1000) > > > Clearly it's early days yet - I've written no

Re: Add support for get_or_none?

That's actually not a bad idea at all, much better than get_or_none(). Cal On Tue, Mar 25, 2014 at 7:20 AM, Cheng Chi wrote: > What about name it fetch()? > > > On Friday, March 14, 2014 3:45:31 AM UTC+11, Cal Leeming [Simplicity Media > Ltd] wrote: >> >> Seems this

Proposal for prepared statements API

I've been discussing this idea for some time now, and was reminded of it recently... and akaariai has pushed me to put forward this proposal. Prepared Statements. The benefit of prepared statements, for those who don't know, is it avoids repeating the time the Query Planner in the DBMS takes to

Re: Add support for get_or_none?

What about name it fetch()? On Friday, March 14, 2014 3:45:31 AM UTC+11, Cal Leeming [Simplicity Media Ltd] wrote: > > Seems this issue was brought up several years ago, though the thread was > later hijacked for other functionality and get_or_none fizzled out. >