Dear Micheal, Wow, thank you very, very much for taking your time with clarifying my problem, this is exactly what I'm looking for. I had problems understanding polymorphic associations, I'll try to go through it again with the examples and the test code provided.
I probably should have mentioned from the start for clarity that Entity Systems has very large similarities with AOP where the Components are similar to Aspects in AOP. It would have saved the guessing work of my problem :( You are spot on when you said that each row of any Component's data is specific to a specific Entity. Regards, Peter Lim On Wed, Nov 6, 2013 at 8:16 AM, Michael Bayer <mike...@zzzcomputing.com>wrote: > > On Nov 3, 2013, at 5:41 AM, Peter <madp...@gmail.com> wrote: > > Hi, > > I'm currently learning the how to set up a basic Entity System with > sqlalchemy. The entity system requirements are described within this link: > http://t-machine.org/index.php/2009/10/26/entity-systems-are-the-future-of-mmos-part-5/ > > > Basically, an Entity that lives with the world is defined by the > Components that are attached to it. The nature of the Entity is described > by the combinations of Components attached to the entity. An Entity can > change it's nature by removing or adding a Component to the entity. Every > Component is backed by a table with it's associated data. The Components > are indexed within the 'components_dir' table. As you can see by the schema > below, each Entity can be mapped differently to different Components based > of EntityComponentMap and this can change anytime with the state of the > object. > > > > OK I tried to scan through that post a bit to get a handle on what schema > it was proposing, but it wasn’t entirely clear. The schema you’ve > presented here gives me a better idea. These kinds of schemas are very > common, but I would note that they are troublesome, both in terms of > scalability as well as querying ability, due to being overly generic. > Like if you have three types of Entity, you can’t easily query for Entity > objects of just one particular type as you have all types of entities > jumbled into the same set of tables. If an entity of type Q has > attributes A, B and C, you can’t easily produce a query that’s equivalent > to “SELECT * FROM Q where A=1 AND B=2 AND C=3”, because you don’t have “A, > B, C” columns - you have to produce joins out to the Component tables in > order to figure these things out, producing complex and inefficient > queries. If your system has many different types of objects, some of which > there’s only a handful and others of which there are millions, they all get > stuffed into the same set of tables, turning those tables into bottlenecks > for all object access. > > > > In order to grab an Entity's component data, I'll retrieve the Component's > tablename via ComponentsDirectory. I'll then manually retrieve the data row > with component_id from it's individual component table. > > > so the next part here, is I didn’t see the term “tablename” in that blog > post at all, but I didn’t read it fully. The practice of joining out from > a single foreign key out to the primary key of table A, B, or C based on a > string tablename in another column is sometimes called a “generic foreign > key”. In relational algebra and SQL, there is no such thing - it’s an > artificial concept created in application space (and is very popular in the > Rails world) that works against the spirit and common practice of > relational databases. I wrote an old post about it here: > http://techspot.zzzeek.org/2007/05/29/polymorphic-associations-with-sqlalchemy/ > and very recently I’ve updated the examples in SQLAlchemy itself to > include modern versions of each. In SQLAlchemy 0.9 the examples include a > pure “generic foreign key” where the “tablename” (more specifically a > “discriminator”) is stored and used as a means of selecting the related > table (this is in examples/generic_associations). > > The key here is not so much having a string that says “this object is of > type X”, SQLAlchemy does have a system called “table inheritance” which > uses this, it’s the foreign key part. When a column can point to any > number of other columns elsewhere, it works against standard relational > techniques and also makes proper data constraints more difficult to produce. > > In the case of your specific model, I’ve made the observation that a > Component seems to have data fields on it, which, though I’m not sure, seem > to be specific to a specific Entity? In which case we can safely make a > row in Component a foreign key out to Entity directly. I’ve adapted this > into a joined inheritance scheme attached which is one way of achieving the > basic idea here, though the specifics might not match what you’re looking > for. Using the separate ComponentsDirectory entity in order to get at > “discriminator” values, rather than having a simple column on > ComponentBase, makes the model much more complicated, but I’ve tried to > work that out here as well just to illustrate that also. > > > > > > > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
