Re: db_type is called more than documented.

2013-11-21 Thread Anssi Kääriäinen 
It seems the db_type() method has been called as part of WhereNode 
construction always (that is, first commit introducing it is QuerySet 
refactor in 2008). So, the docs are wrong. If the result is expensive to 
calculate, you'll need to cache it.

I created a ticket for this, see 
https://code.djangoproject.com/ticket/21478#ticket

 - Anssi

On Thursday, November 21, 2013 9:25:56 AM UTC+2, schinckel wrote:
>
> I maintain the django-jsonfield module, and I have, as the documentation 
> suggests, some relatively expensive code in JSONField.db_type.
>
> The documentation is pretty clear on this as being _the_ place to put a 
> test like this (that checks to see if the database can handle a json field 
> type, or if we should just store it as text).
>
> 
> https://docs.djangoproject.com/en/dev/howto/custom-model-fields/#custom-database-types
>
> "The 
> db_type()
>  method 
> is only called by Django when the framework constructs the CREATE TABLE 
> statements 
> for your application – that is, when you first create your tables. It’s not 
> called at any other time, so it can afford to execute slightly complex 
> code, such as the connection.settings_dict check in the above example."
>
> However, I noticed that the SQL query I was running to check for if I 
> should use a json field was running way more than expected.
>
> It turns out that this method is called at:
>
> 
> https://github.com/django/django/blob/master/django/db/models/sql/where.py#L368
>
> All other calls to this method appear to be in CREATE statements.
>
> Is this something that just slipped under the radar? Is it something that 
> should be fixed in documentation? Any suggestions?
>
> Regards,
>
> Matt.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0338c0f8-941a-4736-998d-f47d55261ad3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Related manager remove() and clear() methods - backwards incompatible changes

2013-11-21 Thread Anssi Kääriäinen 
On Wednesday, November 20, 2013 5:17:11 PM UTC+2, Shai Berger wrote:
>
> Hi, 
>
> On Saturday 16 November 2013 21:02:00 Anssi Kääriäinen wrote: 
> > Any feedback for pre/post_update idea? 
> > 
> As Loic said, the signals sound like they can be useful in a variety of 
> situations. A couple of notes, though: 
>
> > pre_update listeners get a queryset that isn't executed. 
>
> The "query" part, only, I assume; then they should also somehow get the 
> intended update parameters. Perhaps the actual keyword arguments to 
> update(). 
>
> > Accessing that queryset might be costly 
>
> Accessing objects from that queryset may be a footgun -- if they somehow 
> stay 
> in memory after the update is executed, they will become stale. There 
> should 
> be stern warnings about this in the documentation, or even -- and this is 
> just 
> thinking outloud, I haven't considered all the evil effects -- holding 
> weakrefs 
> to all these objects and using the new model reload mechanism to refresh 
> them 
> after the update. 
>

The current idea is to only add post_update with pk_set and kwargs to 
update as data.

Unfortunately such a signal doesn't cover all usage cases - for example if 
you want to do database change tracking using signals, you can't do it with 
the above approach. We (as in I and Loic Bistuer) have tried a lot of 
different approaches to the update signals problem. It seems no matter what 
idea is tried it always fails in some cases, or adds a lot of API/code 
complexity.

Why not post_update with a queryset? If you need a queryset it is easy to 
construct inside the signal from the pk_set. But if you need the pk_set 
only you can't get that back from the queryset in any cheap way. In 
addition the queryset must be constructed with pk__in=pk_set, and such 
querysets can be expensive or impossible to execute (sqlite more than 1000 
parameters exception for example). Finally the pk_set calculation will be 
cheap on databases which implement RETURNING.

Why not pre_update? It turns out this one will be expensive to implement in 
a way that is race-free. We must execute .select_for_update() query before 
pre_update, and after that we need to use 
pk__in=pk_set_from_select_from_update for the update query. Add in the 
pk__in=large_set problem and this doesn't feel like a good addition.

The real problem here is that no matter how we design our signals framework 
it will be either leaky, or horrendously expensive. Just imagine what it 
means to update a field for a large table if you will need to fetch both 
pre/post images for each row. A signals framework that actually works for 
database auditing would need to come with a disclaimer: "Not usable in most 
projects due to performance reasons".

So, now the question is, is the suggested post_update signal a good 
addition to Django?

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ada90f81-d526-48cc-871a-6c227ca66b1c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to livereload Django templates?

2013-11-21 Thread Nikolay Georgiev 
I found a very simple solution using Grunt and a browser extension:

https://github.com/sinnwerkstatt/sinnwerkstatt-web/blob/master/Django-livereload.md
http://stackoverflow.com/a/20135843/2510374

Nikolay

On Monday, November 18, 2013 11:12:26 AM UTC+1, Elyézer Rezende wrote:
>
> On Fri, Nov 15, 2013 at 1:32 PM, charettes 
> > wrote:
>
>> Hi Nikolay,
>>
>> You could implement such a feature as a third party app by connecting a 
>> receiver to the 
>> template_renderedsignal.
>>
>
> To do a live reload the tool need to know when the template in filesystem 
> is updated, then using template_rendered will not help because need to make 
> a request and the live reload is to automatically do that request when some 
> file is updated.
>
> I don't know if will be possible to add that to django itself, but I think 
> that using some tool like watchdog [1] could help doing that.
>
> Other idea is to override the development server command to monitor the 
> changes to templates files. 
>
> [1] 
> https://pypi.python.org/pypi/watchdog
>
> -- 
> Elyézer Rezende
> http://elyezer.com
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8a921146-3ace-4f9f-a9e5-6db687a915dc%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

ManyToMany relationship can't be saved

2013-11-21 Thread Adam Smith 
As I was learning the Django Docs (
https://docs.djangoproject.com/en/1.6/topics/db/models/#extra-fields-on-many-to-many-relationships),
 
I found the following code not working. Is it a bug? At least the result is 
unexpected.

ringo = Person(name="Ringo")
beatles = Group(name="Beatles")
m1 = Membership(person=ringo, group=beatles,
date_joined=date.today(),
reason='whatever')
ringo.save(), beatles.save()
print m1.person.id, m1.group.id  # yes, they have values.
m1.save()  # IntegrityError: membership.person_id may not be NULL


Why can't m1 be save, since both its foreign key fields have been save 
successfully?

Thanks.
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1d4d456f-abff-48fe-bf4c-0014c50abe9c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ManyToMany relationship can't be saved

2013-11-21 Thread Curtis Maloney 
At first glance, I'd guess it's because the PK for ringo and beatles
haven't been updated in the instances you have.


On 22 November 2013 16:31, Adam Smith  wrote:

> As I was learning the Django Docs (
> https://docs.djangoproject.com/en/1.6/topics/db/models/#extra-fields-on-many-to-many-relationships),
> I found the following code not working. Is it a bug? At least the result is
> unexpected.
>
> ringo = Person(name="Ringo")
> beatles = Group(name="Beatles")
> m1 = Membership(person=ringo, group=beatles,
> date_joined=date.today(),
> reason='whatever')
> ringo.save(), beatles.save()
> print m1.person.id, m1.group.id  # yes, they have values.
> m1.save()  # IntegrityError: membership.person_id may not be NULL
>
>
> Why can't m1 be save, since both its foreign key fields have been save
> successfully?
>
> Thanks.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1d4d456f-abff-48fe-bf4c-0014c50abe9c%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDH7KqXhJCdEdo7QGGOhD7P3hubKLSYEgpu%3D8VBaXHQEA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.