Hi,
I've been looking a bit at the issues surrounding primary/foreign keys as
separate entities as well as combined keys. I have a few ideas (basically
an extension of Fedor's suggestions) and I would like some input.
To begin with. Can we live with the fact that we don't use a 100% correct
presentation of a database, but one that will work 90% of the time? If you
need something more elaborate you can move to Osage or Castor or something
else. Good enough will do? :-)
To go about better foreign keys support we need go through a number of
steps. First we need a way to make MapBuilders and BasePeer aware of
combined Keys. To create keys we could create a ForeingKeyMap class that
holds this information.
ForeignKeyMap fkm1 = tMap.createForeignKey("aForeingTable");
fkm1.addColumn ("aLocalColumn","aForeignColumn");
fkm1.addColumn ("anotherLocalColumn","anotherForeignColumn");
To have multiple foreign keys we make multiple calls to createForeignKey().
For starters we could leave the isForeignKey() method in the ColumnMap and
write an implementation that tries to find that column in the ForeignKeyMaps
for that table. This method should then be marked deprecated while we are
working to remove it from all the code.
After this we need a way to represent this in torque. I'll be willing to
add the functionality in newtorque. The xml can look something like this
<table name="table1">
<column name="col1" type="int">
<column name="col2" type="int">
<column name="col3" type="int">
<column name="col4" type="int">
<foreign-key table="ForeignTable">
<column local="col1" foreign="foreign1">
<column local="col2" foreign="foreign2">
</foreing-key>
</table>
The two most prominent parts where isForeignKey() is used is in BasePeer and
torque. Torque shouldn't be to big a problem to fix.
In BasePeer.createQueryString() information about the foreign keys is used
to create simple joins if necessary. This is doable. In
BasePeer.doDelete() the isForeignKey() method is also called. It seems as
if multiple deletes is done here, I'm not sure. Maybe somebody can shed
some light on this method.
When the above mentioned changes are implemented Foreign Keys should be ok.
Primary Keys represent a whole new challenge altogether. The biggest issue
lies with IDBroker and BaseObject. These two classes relies on the fact
that a table has *one* column that acts as the id.
I don't really have any ideas of how we would implement this. As far as I'm
concerned we just let users know that we require each table to have one
column designated as the id column. This is good db design anyway.
If we go for the above changes should we maybe consider moving to something
like Peer version 2. Could be an excuse for a nice clean break to JDBC2 as
well. Just a thought - any comments suggestions?
~ Leon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
