> Actually the labs where just an example: one laboratory will
> have one installation of the application, and the dynamic
> fields will only apply within the scope of this installation.
> There's no such thing as consistency accross labs.
It still sounds like the above scheme would do the trick...one
code-base could work for any of the installations.
> Well, that's what I almost did... with support for
> enumerations (some fields must only accept predetermined
> values):
>
[snipped]
>
> However, watching the MySQL verbose log, I realized that
> retrieving properties as well as their definitions (and
> enumeration values) to properly display an detail view or
> edition form execute a _lot_ of SQL queries, when this could
> be achieved with one or two joins... I'm afraid it won't
> scale.
>
> Or does your "ManyToMany(Values)" field helps for
> optimization? May I expect any help from manipulators,
> managers, query sets (all of these are still a bit obscure to
> me) ?
ManyToMany neither helps nor hinders performance...it states a
fact about your model. For performance, you may want to try
using the Model.objects.select_related() call. This pulls in the
items related to your search, so you can do things like
MediaItem.objects.filter(author='Smith').select_related()
This should help reduce the number of hits on the DB by telling
Django to pull them all back in one pass.
This scheme does have one small complicating factor wherein if
you want MediaItems with property1='foo' and property2='bar', you
have to jump through some hoops. Some dark-art SQL-foo can solve
the problem, but it's not a pretty scene. As long as you only
limit it one property, Django's good:
items = MediaItem.objects.select_related().filter(
property__category__name='MyProp'
).filter(property__value='MyValue')
(adjusting for your model). Asking for multiple properties is
akin to asking
SELECT * FROM tblFoo WHERE x=1 AND x=2
and returns no rows (because there's no way to have x be both
values...unless you have
> SELECT Owner FROM tblCat WHERE state='alive' AND state='dead'
Owner
============
Schroedinger
...a little feeble SQL/metaphysics humor there)
However, if you know which piece of your cross-cutting will have
the smaller results, you can do things like the above and then
filter the resulting items based on whether they have properties
2..N such as
new_items = []
for item in items:
for property in item.property:
if (property.value=='MyValue2' and
property.category.name=='MyName2'):
new_items.append(item)
It's not ideal for high volumes of data or high volumes of
traffic, but should be sufficient for most small uses.
-tkc
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
