Re: [SQLObject] Foreign Key + Constraints?

[Ian B. <ia...@co...>]

I haven't looked at the patch in context yet, but a couple comments...

On Dec 3, 2003, at 12:43 PM, Sidnei da Silva wrote:
> Ok, attached is my first try. There's two things I would like to
> discuss before going on supporting the other databases:
>
> First, I'm getting the 'foreign' class via findClass(col.foreignKey),
> without passing the registry parameter, because AFAICT, I can't get to
> the SQLObject class from the column. Is that correct? How much trouble
> can that buy us? :)

SOCol should get the foreign class, but not during instantiation 
(because it's instantiated when the class is created, but the foreign 
class may not be instantiated yet).  There should be a function that 
gets called in SOCol when the foreign class is created, and you should 
set up anything you need then.

> Second, I think that as I'm getting the 'dependent'[1] classes via
> findDependencies, It would be simple to pass them into
> DBConnection.dropTable() so that we can do the cascade the manual way
> -- by iterating on the result of select() and calling destroySelf() on
> each object. Does that sound reasonable?

You mean, delete every instance from the table, then delete the table?  
Hmm... dropping a table is a pretty severe thing whatever way you do 
it, I'm not sure how important destroySelf is at that point.  OTOH, 
maybe if you just want to drop without any checks (and presumably 
restart your process), you should do it with plain SQL and not the 
class method.  (E.g., test code will want to do that drop, so it can 
start from a consistent state regardless of previous possible 
corruption)

> [1] I considered 'dependent' a class that has a column which refers to
> our class on the 'foreignKey' attribute, and also has 'cascade' set to
> True.

I suppose it follows that if the rows are dependent, the table as a 
whole is as well.  OTOH, that wouldn't occur to me naturally -- it's 
something of a corner case.  The principle of least surprise would 
indicate that we should leave the table around.  But that's no good, as 
we're inconsistent at that point.

And what about circular dependencies?  These can only happen if NULL is 
also allowed in the foreign key, but it does happen.  In this case we'd 
want to NULL out the one table, remove the first, then maybe remove the 
second.

--
Ian Bicking | ia...@co... | http://blog.ianbicking.org