Tim Chase wrote:
>> 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, not really. Think of an installation as a "site" in Django, I'm currently
working on the "application". Administrators are expected to add/remove dynamic
fields within the scope of a given site. In other words, it's some sort of
site-specific configuration.
>> 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.
Thank you (and to Gulopine) for pointing this out.
> 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')
Okay
> (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
I see
> > SELECT Owner FROM tblCat WHERE state='alive' AND state='dead'
>
> Owner
> ============
> Schroedinger
>
> ...a little feeble SQL/metaphysics humor there)
Apparently we're not going to deal with cats ;)
> 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.
Okay, I got the point.
Now, there's another problem with the above method: it doesn't play nice with
Django's auto-admin interface and generic views. Additionally, that makes 4
models for what is conceptually one thing : a media item.
What about a radically different idea: a command line tool that would "modify"
the models and SQL tables in one go. Say something like:
$ telemeta-admin addfield musicians charfield
This would retain all of the power/simplicity of Django admin interface. I'm not
sure how this could be generalized to get included into Django's manage.py, but
a such command line tool would be rather feasible within the scope of telemeta.
However, I don't like the idea of modifying the python models code with this
tool. I'd prefer the models to be customized by loading some external fields
definitions, say from an XML file.
I'm still a python newbie, but it seems to me that there could be a way to
modify the model definition before Django knows about it:
=== start of models.py ===
class MediaItem(models.Model):
"Describe an audio/video item with metadata"
title = models.CharField(maxlength=250)
author = models.CharField(maxlength=250)
# Parse some external XML file defining the dynamic fields and then add them
# to the class definition with something similar to:
MediaItem.foobar = models.CharField(maxlength=250)
=== end of models.py ===
I tried it: when I load the model withing the python shell, the class does have
a foobar attribute. However, when I run python manage.py sql, the foobar field
is gone...
Any idea?
--
Olivier - http://www.samalyse.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
