Hi Jay,
In general, the EJB 2.0 specification is written to an audience of
developers of enterprise systems. In my opinion, the maintainers of
the database schema for such a system would not be amenable to
change for a reason like "spec compliance of the persistence
manager," in the absence of real business requirements. And in
general, such change isn't necessary--the specification for EJB 2.0
CMP entities is designed to allow for full-featured object/relational
mapping capabilities in the persistence manager.
"Disconnected objects" have a valuable purpose for dependent
objects that participate in a many-to-many relationship. My opinion
is that the requirement to allow for these disconnected objects in a
one-to-one or one-to-many containment relationship was for
consistency with many-to-many relationships.
-Dan
On 2 Nov 00, at 10:39, Jay Walters wrote:
> Do you know if that is a requirement (or even a goal) of the spec, no
> changes to an existing normalized schema to use CMP? I agree it does not
> look possible to map from your schema to one which will support the spec
> without some work on the database.
>
> Cheers
>
> -----Original Message-----
> From: Dan OConnor [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 01, 2000 2:29 PM
> To: jBoss Developer
> Subject: Re: [jBoss-Dev] EJB 2.0 spec question
>
>
> Hi Daniel,
>
> Your two cents are always welcome. Your solution does allow for a
> disconnected object as per the specification. However, a deployer
> should be able to map an entity using the EJB 2.0 CMP model
> without changing an existing normalized schema... especially if it
> would mean changing existing data. It would be inappropriate to
> require an organization to change existing line-item numbers (that
> might be used for various business purposes) just to take
> advantage of EJB technology.
>
> I believe the schema I described is quite common in practice.
>
> -Dan
>
> On 1 Nov 00, at 12:04, Daniel Schulze wrote:
>
> > I give my two cents without beeing asked...
> >
> > Why not like this (in my eyes somehow "cleaner", relationships can be
> > added, removed, changed whithout affecting the data, data can be changed
> > without affecting relationships in case a bean becomes replaced by a new
> > version).
> > Every relationship has its own mapping table:
> >
> > TABLE: order
> > order_number (not null and the pk)
> > customer
> >
> > TABLE: line_items
> > line_item_number (not null and pk, implizit created by the persistence
> > manager and for user and developer transparent)
> > product
> > quantity
> >
> > RELATIONSHIP TABLE: order-line_items
> > order_number
> > line_item_number
> >
> > This would be easier to handle especially when the objects have many
> > relationships.
> >
> > BTW I dont think the mentioned paragraph from the spec makes sense,
> > because it violates the idea of dependend objects (only exist as an live
> > reference of a bean).
> >
> > \Daniel
> >
>
>
>
