On 9/12/2012 5:54pm, Thomas Lockhart wrote:
On 12/8/12 5:37 AM, Derek wrote:
Rather than use a trigger (which is DB-specific and also hard to debug
because not part of your code base), suggest you use signals[1].
Hmm. Triggers have advantages over application-level code where they can
be used. They are likely more efficient (no data needs to be transferred
to the client) and are more likely to ensure data integrity (by
operating within a database transaction in an atomic fashion, and
without application-level edge case failures). For cases like this one,
debugging should be pretty easy because one can add or increment values
in a table and watch the trigger do the additional work.
That's not to say that signals aren't a great feature, just that compact
trigger code can have advantages
For the sake of maintainability it might be better to keep all database
manipulation in the model layer rather than split it betweem models and
database.
and, well, that code is part of the
code base too.
Which means you need to keep pretty comprehensive documentation if you
are doing database stuff in two areas.
Personally, I'd keep it all in the django ORM until the project is
mature and requires the final molecule of optimisation.
Mike
- Tom
Derek
[1] https://docs.djangoproject.com/en/dev/topics/signals/
On Saturday, 8 December 2012 04:27:50 UTC+2, Chris Cogdon wrote:
It's a simple performance vs storage question.
Storing a calculatable field also risks it getting out of sync
with reality, but if you're doing the query on that _so_ much,
then its usualyl worth it.
Also, with the right database and a trigger, that's something the
database can ensure for you. Ie, a field that the database updates
for you.
On Friday, December 7, 2012 5:54:37 PM UTC-8, Victor Hooi wrote:
Hi,
I have a "ranking" field for an item that returns an integer
between 1 to 10 based on a number of criteria of each item.
My question is - what are the pros and cons of using a model
method to return this, versus overriding the save() method and
saving it directly into a normal IntegerField on that item?
I understand that model methods *won't* let me use them within
QuerySet filters on that item - is there any way around that?
If I just override the model's save() method to get it
recalculate and save that field each time, I can use it within
QuerySet filters. Any cons with that approach?
What do you guys tend to use in your projects?
Cheers,
Victor
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/G7fp5OLkapgJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
