[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@ninjaneering.com
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@twistedmatrix.com [mailto:twisted-python-admin@twistedmatrix.com]On Behalf Of Sean Riley Sent: Saturday, September 07, 2002 4:35 PM To: twisted-python@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@ninjaneering.com _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Sun, 8 Sep 2002 15:48:58 -0500, "Sean Riley" <sean@twistedmatrix.com> wrote:
I don't think anyone else was using the existing code; it needed some of the changes you've just mentioned first :-)
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 names of these attributes look a little sloppy. Could they have a consistent prefix to give readers of the code a hint at what they're looking at? I would propose "rowColumns, rowKeyColumns, rowTableName, rowForeignKeys", as long as we're breaking compatibility. This looks like a good evolution of the ROW interface. How stable do you feel this new iteration will be? -- | <`'> | Glyph Lefkowitz: Traveling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |
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@twistedmatrix.com [mailto:twisted-python-admin@twistedmatrix.com]On Behalf Of Sean Riley Sent: Saturday, September 07, 2002 4:35 PM To: twisted-python@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@ninjaneering.com _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Sun, 8 Sep 2002 15:48:58 -0500, "Sean Riley" <sean@twistedmatrix.com> wrote:
I don't think anyone else was using the existing code; it needed some of the changes you've just mentioned first :-)
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 names of these attributes look a little sloppy. Could they have a consistent prefix to give readers of the code a hint at what they're looking at? I would propose "rowColumns, rowKeyColumns, rowTableName, rowForeignKeys", as long as we're breaking compatibility. This looks like a good evolution of the ROW interface. How stable do you feel this new iteration will be? -- | <`'> | Glyph Lefkowitz: Traveling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |
participants (2)
-
Glyph Lefkowitz -
Sean Riley