Hard to come up with an appropriate subject for this question..
Here's the issue:
(The site is a small-theater company management app)
I have a model 'Patrons' which encapsulates all of the people that I want
to track in my site. A Patron is anyone who's done anything with-or-for
the theater company. In order that I don't have to keep track of
all kinds of information for all kinds of Patrons, I want to have
'plugins' which 'attach' to the Patron record. For example, when someone
signs up to audition for a show, they get an "Auditioner" object
attached to their Patron object. The "Auditioner" object encapsulates
information that the director of the show will need (when, voice type,
age, height, etc.) things that we normally don't care about for most
patrons. Most patrons will going to shows, so they will have "TicketPurchase"
objects attached to their Patron object, keeping track of all of the
ticket purchases that person has made.
My initial thought is something like this:
class Patron(models.Model):
last_name = models.CharField( ... )
first_name = models.CharField( ... )
addr = models.CharField( ... )
.. etc ..
class Auditioner(models.Model):
patron = models.ForeignKey(Patron)
audition_date = models.DateTimeField( ... )
.. etc ..
class TicketPurchase(models.Model):
patron = models.ForiegnKey(Patron)
num = models.IntegerField(...)
show = models.ForeignKey(shows.Show)
.. etc ..
Now what I want to display in a list view of patrons is:
Last, First ... Audition? TicketPurchase?
Cuddy, Michael Y Y
Smith, John N Y
...
Where the 'Y' (or 'N') indicates whether or not the Patron has that
particular kind of data attached to their Patron object (and in a real site
would be links to go look at / modify that data). Not all patrons
will have all plugins associated (Also, ideally, the view for patrons
would not know 'ahead of time' what all of the plugins were -- new ones should
be able to be added at a later date and not disrupt the existing data.
The number of patrons will run into the thousands. The number of 'plugins'
is initially planned to be around 10-15.
My zero'th thought was some kind of object inheritance, but django
doesn't support that, and it's messy, and, and, and ... so I didn't really
think about that too much :-)
My first thought was LEFT JOIN'ing the tables, but that has a number of
issues: first, it drops to raw SQL and kind of violates the django-ness (!?)
of the site. Second, LEFT JOINs with more than a couple of tables
starts to be a real performance bottleneck.
My next thought was that since the primary access for lists of
people will be through the patron model (frankly, most of the queries
will be alphabetical or searching for a specific patron by name),
so when generating a view of patrons, it's probably not that bad
to just do the individual queries for each record displayed on a
particular page hit. I could probably come up with a 'patron_id__in = [..]'
type query and run that across the plugins which would allow me to do one
query per plugin once the set of Patrons to show on a particular page has
been determined; and that's not too bad.
However, I'm interested in any ideas anyone else might have for this.
One more (maybe) cog in the works: some plugins (like the aforementioned
"Auditioner" and "TicketPurchase" will have many entries per Patron.
Some plugins, like "Staff", the one which holds login auth information
will be one-entry per Patron.
--
Mike Cuddy ([EMAIL PROTECTED]), Programmer, Baritone, Daddy, Human.
Fen's Ende Software, Redwood City, CA, USA, Earth, Sol System, Milky Way.
"The problem with defending the purity of the English language is
that English is about as pure as a cribhouse whore. We don't just
borrow words; on occasion, English has pursued other languages down
alleyways to beat them unconscious and rifle their pockets for new
vocabulary." -- James D. Nicoll
Join CAUCE: The Coalition Against Unsolicited Commercial E-mail.
<http://www.cauce.org/>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
