Hi Dave,
BTW, I assume it is understood here, but this is general discussion and
not aimed at you or anyone else specifically.
I disagree with your statement ( separated by dashed lines ) below.
While individual apps ahould not concern themselves with all details of
deletion ( and often with inserts or updates, ) there should be business
rules encapsulated and enforced somewhere to govern when, how and where such
operations should be performed.
If an app takes upon itself the task of deleting items, it should be
aware of system effects. Otherwise, such operations should really be a
request to an entity that knows how to handle them. A system that blindly
allows deletion of catalog entries in one area, but has sales fulfillments
that rely on that entry is design impaired and has no integrity at all.
These notions impact many kinds of systems and a developer who ignores them
in relational systems will do no better in OO and other types of design.
Joe Sam
-----Original Message-----
From: David Brown <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wednesday, May 12, 1999 1:03 AM
Subject: Re: relational storage (was "Re: Granularity of EJBObjects")
>* Data Integrity Failure. Now, maybe I didn't get it, but I could
>never get cascading deletes to work properly in relational databases. I
>always ended up turning them off and doing it manually as soon as I had a
>second application running against the same data. Different applications
>manipulate relationships differently.
----------------------------------------------------------------------------
--------
>One application does not (and should not) know how to properly
>delete records so as not to affect the other.
----------------------------------------------------------------------------
--------
>Take for example a Sales Order system. It may maintain product catalog.
If
>a product is no longer offered for sale, it may delete the product from the
>system (okay, what about the orders that point to that product?). Add a
>manufacturing application to the same system. It tracks bills of material,
>that list products. We now have many different references to the same
>product record, and no clear way to know when, if ever, it can be deleted.
>An object based repository, like GemStone/J, if it has multi-user,
>distributed, disk-based garbage collection, can manage this problem
>automatically. The product record will remain as long and only as long as
>there is a reference to it. This is a big requirement for reusable object
>models.
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
