[Twisted-Python] relationships in t.e.row

[Sean Riley]

i now have a working version of relationships in t.e.row that also includes
simplifying the interface a little. It is however incompatible with the
existing version of the code...

Is anyone using t.w.row and if so, do they object to changes to add this
functionality even if it breaks existing code?


The new interface uses class attributes instead of the "stubs" stucture and
removes all of the class mutation that was being done.  Now, to define a
class for a database table looks like:

class FurnitureRow(row.RowObject):
    rowColumns    = ["furnId", "roomId", "name", "posx", "posy"]
    dbKeyColumns  = [("furnId","int4")]
    tableName     = "furniture"
    foreignKeys   = [("testrooms", [("roomId","int4")],
[("roomId","int4")]) ]

full code and docs to follow if no-one objects.


-----Original Message-----
From: twisted-python-admin at twistedmatrix.com
[mailto:twisted-python-admin at twistedmatrix.com]On Behalf Of Sean Riley
Sent: Saturday, September 07, 2002 4:35 PM
To: twisted-python at twistedmatrix.com
Subject: [Twisted-Python] relationships in t.e.row


a natural extension of twisted.enterprise.row is to add support for
relationships between tables.

anyone got any good examples of tools or apps that do this well?

Some initial thoughts..

Currently, the reflector is initialized with the "stubs" structure that
consists of:

	stubClass, tablename, keycolumns

for each (database table / row class). This information could be extended to
include some relationship data in the form of foreign keys. This foreign key
data would allow relationships between tables in the database to be mirrored
into the reflector.

For example, in the existing row example code the stubs structure is:

stubs = [ (RoomRow, "testrooms", [("roomId","int4")]) ]

If there was another table "furniture" and a foreign key in that table that
connects it to the room table, then that could be specified when
initializing the reflector:

stubs = [
  (RoomRow,      "testrooms", [("roomId","int4")]), [] ),
  (FurnitureRow, "furniture", [("furnId","int4")]), [("roomId", "int4",
"rooms", "roomId")] )]

where the forth element in each entry is a foreign key of :
	(local_column_name,
	 column_type,
	 foreign_table_name,
	 foreign_column_name)

(could specify the foreign class also, but the reflector should already know
which class corresponds to the foreign table.)

This foreign key data would then be used when loading row objects from the
database. Any time a "RoomRow" object is loaded, it would load all of the
FurnitureRows for that room.  Although the foreign key data is specified for
the child table (furniture) it is when objects of the parent table
(testrooms) are loaded that the significant work happens.

Allowing an option for child rows to be loaded when loading a row is
probably a good idea.

This probably requires some changes to t.e.row to work. Currently the
optional "factoryMethod" is passed into Reflector::loadObjectsFrom. The
factoryMethod will need to be available for children classes also, so it
probably should be added to the stubs structure.

The "data" passed to loadObjectsFrom is also an issue, maybe the data passed
into the highest level loadObjectsFrom is passed down to children, or the
parent Row instance that the rows are being loaded for is passed as the
data...? Maybe loadObjectsFrom takes a parent object every time it is
called - this may even be required.

The relationship between rows once they are loaded is another issue. Where
are children row objects put once they are loaded? In the above example,
maybe the RoomRow object has a list member variable called "furniture" or
"children" added to it and the FurnitureRow objects are put in that list?
This becomes a type of containment system with a heirarchy of containers...

So, loading row objects is doable. I'm not sure of all the implications for
other SQL operations. Assuming that all changes to the database are going
through the row interface makes things easier, but it requires more
thought... A good goal is to be able to operate on these row objects in
memory and have the changes propagate into the database in  controllable
way.



----------------
"If he's so smart, then how come he's dead?", Homer Simspon
Sean Riley
sean at ninjaneering.com


_______________________________________________
Twisted-Python mailing list
Twisted-Python at twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python