modeling complex data with sqlalchemy

[Littlefield, Tyler]

Hello:
Thanks for the info. IT doesn't really model the data I wanted. The 
contents was easy enough, I'm just going to set up a 1:n relationship on 
the Entity to the actual player. But for components, it's a bit different.
Each component inherits the actual Component class, and has a number of 
attributes on it. I can't just put it in it's own. So I was going to set 
up a table per component and then just store an id and another id for 
what holds it. But my problem is modeling it. I also need the inherited 
data from Component. Would there be a way to do this? I could have:
id, name, component_id
and then SA could use the name as the table's name, and the id as the id 
of the component in the other table.
How would I set this up with SA? Is it a good idea to go this route?

On 8/25/2012 5:53 PM, Dennis Lee Bieber wrote:
> On Sat, 25 Aug 2012 14:47:35 -0600, "Littlefield, Tyler"
> <tyler at tysdomain.com> declaimed the following in
> gmane.comp.python.general:
>
>> Hello all:
>> I had a quick question.
>> In my game, I have an is-a setup, where all objects contain data like an
>> id for sqlalchemy, a name, a description and a list of contents.
> 	Well, a "list of contents" comes down to a table of items with a
> foreign key to the item "containing" them...
>
> create table objects
> (
> 	ID	integer auto-increment primary key,
> 	name	varchar(?),
> 	description	varchar(?)
> )
>
> 1, Wulfraed, something or other
> 2, Bag of Holding, whatever
> 3, Sword, some cutting comments
> 4, Treasure Chest, everyone wants one
>
> create table holdings
> (
> 	ID	integer auto-increment primary key,
> 	holder	integer foreign key objects(ID),
> 	holding	integer foreign key objects(ID)
> )
>
> 1, 1, 2
> 2, 1, 3
> 3, 2, 4
>
>> In order to add functionality to an object, you add components. So for
>> example, a player would have the Player and Living component associated
> create table attribute_types
> (
> 	ID	integer auto-increment primary key,
> 	name	varchar(?),
> 	type	char(?),	#or an enumeration if supported by the RDBM
> 						#and SQLAlchemy
> )
>
> 1, Player, Boolean
> 2, Living, Boolean
> 3, EdgeWeapon, Boolean
> 4, Damage, DieRoll
> 5, ContainerSize, Integer
> 6, Class, Text
>
> create table attributes
> (
> 	ID	integer auto-increment primary key,
> 	describes	integer foreign key objects(ID),
> 	attribute	integer foreign key attribute_types(ID),
> 	value BLOB(?)
> )
>
> 1, 1, 1, blob(True)
> 2, 1, 2, blob(True)
> 3, 3, 3, blob(True)
> 4, 3, 4, blob("1D8 + 4")
> 5, 2, 5, blob(-1)	#-1 being unlimited, bag of holding
> 6, 4, 5, blob(6)		#treasure chest holds 6 units of objects
> 7, 1, 6, blob("Ranger")
>
>
> 	Now, you could add another layer of indirection -- a table of
> pre-defined object /types/ (different types of containers, swords, other
> weapons), and have each instance (the ones shown in "objects") refer to
> the object type table, and the object type table is what the object
> attributes refers to.
>
>


-- 
Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave.