Gentlemen,
Both points of view have merit.
1. A good object model can use relationships as first class objects
to manage the "can delete?" question. When product item is asked
to delete itself, it can check if it is in any has-a relationships that
would keep it from being deleted.
2. A repository that can detect free floating objects with no references
and automatically clean up is a good thing. In the case where #1 isn't
done well, at least we won't end up with the "ghost reference" problem.
Regards,
-Chris, the peacemaker ;-)
> -----Original Message-----
> From: Joe Sam Shirah [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, April 28, 1999 10:05 AM
> To: [EMAIL PROTECTED]
> Subject: Re: relational storage (was "Re: Granularity of EJBObjects")
>
> 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".
===========================================================================
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".
