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?
>>
>
> Yes
>
>
>> Yes, prepared s
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 in
>> 1.9.
>>
>
> Uhm, st
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 Shai already said he is -
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
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
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 complet
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 makemigrations
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
aren'
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
t
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" %} wit
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
https://docs.djangoproject.com/en/dev/internals/depr
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 persis
On Tuesday 25 March 2014 20:36:39 Marc Tamlyn wrote:
> 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.
>
+1
Shai.
--
You received this message because you are subscribed to
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 ins
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 m
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 workaround you
> menti
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 locall
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 r
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,
you
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 pe
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 co
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 issue was brought up severa
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 f
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.
> https://groups.google.com/forum/
24 matches
Mail list logo
