> > I do not know very many databases but of those I know only 
> Oracle supports
> > CASCADE for example (do you know others?), does MySQL?, etc...
> 
> MySQL does not trouble itself such baroque and performance 
> imparing features ;-)
> No transactions, no foreign keys, no constraints, no 
> triggers... pure readonly
> performance. Just what you need for a running a website (but 
> not a web-interfaced
> application)
> 
> > I think we do not need to support it HERE, I believe in 
> most cases it would
> > be preferrable to perform appropriate action (i.e. cascade delete)
> > programmatically in java. It might even Make sense to add 
> methods such as
> > doDeleteCascade to Peers so that it does the cascade delete 
> and doDelete
> > will raise an exception if you are trying to delete a row with child
> > records.
> 
> We have the meta information, so we might attempt doing that. But on 
> transaction-less db engines, it's still failure prone. The good thing
> is that it would minimise the programmer's error factor.

If you tolerate absense of transactions in other cases this should not be an
exclusion. It is as error prone as anything else, but at least it minimizes
the human factor which is more dangerous than any power failure ;-)

> 
> > Alternatively we can add a parameter to doDelete and doUpdate to
> > tell it whether it should be cascaded or not. I think this 
> way you'll have
> > much better and granular control over this (dangerous) 
> behaviour. Makes
> > sense?
> 
> +1. 
> 
> The crucial part is to fall back to programmatic cascading 
> only when the
> DB does not support cascades.

I think it's a good idea in any case because DB support does not give you
the control over this behaviour. You can only define it when you create the
table. If you, however, use programmatic implementation you explicitly
specify whether you want to delete the record only if it has no children 
or delete any children if there are. An example would be some financial app
where a Clerk would only be able to delete an empty bill (created by
mistake) while a Supervisor would be able to delete any bill whether empty
or not (do not critisize the example).

Fedor.


------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?:           [EMAIL PROTECTED]

Reply via email to