[SQLObject] Re: Re: SQLObject / Oracle

[John Dell'A. <de...@ml...>]

Ian is correct, I simply added REFERENCES to table creation. I purposely did
not add an ON DELETE clause because I want a database error if any funny
business happens.

"Ian Bicking" <ia...@co...> wrote in message
news:2AF...@co......
> On Tuesday, September 30, 2003, at 08:08 AM, Ian Sparks wrote:
> > "John Dell'Aquila" <de...@ml...> wrote in message
> > news:blb1e5$p6t$1...@se......
> >> I don't fully understand the framework yet but I've managed to get
> >> all the
> >> column types working. I also implemented referential integrity
> >> constraints
> >> on ForeignKey columns since I want the tables to be safe for use from
> >> the
> >> database side as well. I also want to get columnsFromSchema
> >> implemented if
> > I
> >> can figure out what's going on from the Postgres implementation.
> >
> > I'd be interested in the Referential integrity additions for porting to
> > Firebird - espcially if you have dealt with the cacheing issue (cascade
> > deletes removing child objects from the cache).
>
> I assume John is talking about REFERENCES in the automatic table
> creation -- which would be a nice addition.  Cascading deletes are...
> challenging.
>
> Right now I'd suggest just overloading destroySelf(), doing the
> cascading manually.  Maybe there could also be a soft destroySelf -- 
> like, remind the object it's dead (but the object doesn't have to
> delete itself from the database).  Either way, you could do it by
> adding an attribute to Col/ForeignKey objects to control it, and then
> handle that in destroySelf.  (And, while we're at it, all the foreign
> key stuff should be moved out of Col and into ForeignKey, though that
> would require a little refactoring to keep it as general as it is)
>
>    Ian
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf