Re: Unknown SQL

>> >> In an OODBMS, the DBMS will not delete the
>> >> enrollment until all the references to it are gone. IE. one must
 delete
>> >> both the student and the class before the enrollment disappears.
>> >
>> >We are just about to release a callback interface for cascading deletes.
>>
>> And this is supposed to be simpler than just declaring a cascading
 delete?
>> LOL
>
>Cascading the delete is exactly one line of code:
>container.delete(member);

One line of code where? In every application that deletes a member?

>In addition the concept is much more powerful than cascaded-delete in
>relational databases. The programmer has manual control to check conditions
>and to take additional actions.

In other words, the programmer has discretion to ignore integrity constraints and an unspoken obligation to reproduce all constraints in every application. Smells like extra work to me.

>> Add Callback to the list of concepts your users must learn and
 understand.
>> Add it to the list of physical implementation details your product
 exposes
>> in the logical interface to the user.
>
>Indeed, this is an additional concept but the programmer does not need to
>worry about it, if he does not wish to use it.

Huh? How can he make the decision that he does not wish to use it unless he first learns about it?

>> When someone decides to switch to a different vendor's OODBMS, how do you
>> propose they transport constraint meta-data obfuscated in a procedural
>> callback function?
>
>Callback events are is common among object database implementations. Since
>all actions taken remain within the users application classes, the feature
>is perfectly portable.

In other words, your OODBMS provides no means of enforcing integrity constraints forcing this vitally important obligation onto your product's users. Callback events are yet another implementation dependent physical construct that your product forces its users to deal with. What happens when the other OODBMS uses a subtly different interface to its callbacks? How is that portable?

In fact, your position boils down to your so-called DBMS being totally ignorant of the data integrity constraints so it has no need to port them anywhere.

>I don't know this, really:
>How are cascaded deletes portable between relational databases?

Very easily. No syntax differences exist that a small Perl script could not automate for the transport. Received on Sun Jul 22 2001 - 01:28:49 CEST