So, the code I posted is a much simplified version of what I'm trying
to accomplish only used to illustrate the error I was getting. What I
actually want to do is select the appropriate class based on any
number of Attributes a Thing might have. I have a metaclass that is
applied to Thing and all it's subclasses. This metaclass does the
actual call to mapper, creates the select query to map against for the
various subclasses, and builds a DRIVERLIST dictionary with data that
can be used by setProperClass. In other words, the "type" of a given
Thing is determined by it's attributes at runtime, not when the Thing
is created.
I didn't run into any functional problems doing it this way in 0.3 so
I'm not sure what you mean by "wrong mapper" (I used assign_mapper if
that makes any difference). The reason I did the setProperClass at
the end of the populate_instance function is because I wanted to make
use of the attrs that the mapper would populate. That seemed like the
easiest way to accomplish the goal at the time.
I've read the "Mapping Class Inheritance Hierarchies" section in the
documentation and it looks like they won't quite do what I'm trying to
accomplish. Maybe if I explained my app architecture a little more
you could clarify the solution a bit (sorry, this ended up being more
verbose than I intended):
I have a datastore that consists of 3 tables.
1. Thing table (just a primary-key name column)
2. Attr table (key/value columns with an id and foreign key to Thing
table)
3. Thing-to-Thing relation table (Things can be 'connected' to each
other)
The idea for that schema is to maximize the flexibility of what one
can store. In this vein I created a Thing class. This class has many
methods for managing attributes, connections between Things,
searching, matching, clever __init__, __str__, __eq__, etc. The
design is such that subclasses of Thing only need to set class
variables to achieve certain functionality. For example, there is a
meta_attrs list that will pre-fill the attributes for an object and
there is also a required_attrs var that will let you define required
arguments to init. My goal was to make sublcasses or 'drivers' as
simple as possible.
To expand on the Server example from my testcode, say I had this
class:
class Server(Thing):
meta_attrs = [('type', 'server')]
def ssh(self):
# start an ssh session to this server
somemagic()
People use that class and do things like:
someserver.addAttr('manufacturer', 'sun')
adding lots of data to the db. Then later someone decides that sun
servers have some special functionality that should be exposed, say cd
ejection. They create a new class:
class SunServer(Server):
meta_attrs = [('manufacturer', 'sun')]
def ejectCD(self):
# eject the cd
It should be that easy. Now, some things I didn't mention earlier.
The all meta_attrs of all parent classes also get applied to new
objects. So any s=SunServer() will have both ('type', 'server') and
('manufacturer', 'sun') attributes. Also, now that I have this new
SunServer class any time I select something from the database that
matches all its meta_attrs it should return a SunServer object where
it used to return a regular Server object.
ex.
t1 = Thing.query.filter(Thing.c.name == 'someOldSunServer')
isinstance(t1, SunServer) == True
This is without updating the database, or making any other change
aside from adding that new SunServer class. So, where does sqlalchemy
fit into all this? People developing drivers shouldn't ever have to
know about SA (they, of course, could make use of it if they want).
The Thing class has a __metaclass__ that takes care of all the SA
magic so every subclass of Thing is taken care of. However, I'm not
sure how to get the polymorfic stuff in the SA mapper to match against
arbitrary attributes of classes (specifically those named in the
meta_attrs). Should I not rely on SA to return any specific type at
all (just always return Thing) and make my own query/select functions
that call _setProperClass on their own?
I'm trying to take advantage of as much of the SA magic as possible,
but I'm unsure when I am going beyond its scope and some of the more
"advanced" topics are not quite documented enough for me to fully
understand how to use them.
Thanks for the help,
-Ron
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
