I would think using a surrogate primary key solves the dilemma, that way
order_number can be nullable.
line_Items is now
line_item_id (not null, pk)
order_id (nullable, foreign key)
line_number (not null)
product
quantity
I'm having a hard time visualizing a case where you want the behaviour which
the spec talks about in terms of detachment, no cascade delete and keep
unnavigable rows around.
Note that in general we would use the cascade delete option for such a
tightly coupled master-detail relationship and in that case we could force
order_id to be not null and make order_id, line_number a unique key; or
bring it back as the primary key. Dependent objects are by definition
objects whose lifetime is managed by another object, and it makes no sense
to have a detail object outlive it's parent.
Cheers
Jay Walters
-----Original Message-----
From: Dan OConnor [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 01, 2000 1:53 PM
To: jBoss Developer
Subject: Re: [jBoss-Dev] EJB 2.0 spec question
Hi Rickard,
Let me try to come up with a case that will illustrate my concern.
Say an order has line items. Define the order table with two
columns:
order_number (not null and the pk)
customer
Define the line_items table with four columns:
order_number (not null, a foreign key, an element of the pk)
line_item_number (not null, an element of the pk)
product
quantity
The order table is the persistent store for an Order entity bean. The
line_items table is the persistent store for a dependent LineItem
object. There is a one-to-many relationship between Order and
LineItem. As such, there is a cmr field with an accessor that
returns a Collection or a Set.
The implementation of the Order entity bean will almost certainly
determine the elements of the Collection or Set by selecting from
the line_items table where the order_number foreign key matches
the corresponding primary key field of the Order entity bean.
If the bean programmer removes a particular line item from the
Collection or Set, the object must be removed from the
corresponding logical relationship between the Order entity bean
and the LineItem dependent object--but it can not be removed from
the persistent store. (It must continue to be accessible by EJB QL
queries.)
My question: what value should be placed in the order_number
column of the line_items table for that dependent object (which can
not continue to participate in a relationship, but must still exist)?
Although it might seem like the right answer should be "null", this
is inappropriate for several reasons:
1. Some databases will not allow a column of the primary key to be
null.
2. The corresponding logical key space may not be large enough
(e.g. if the line_item_number values begin with 1 and are
sequentially numbered for each line item set within an order).
I am left with the idea that the schema must add a boolean column
that indicates whether or not the dependent object participates in a
relationship. But this is an ugly requirement for a very common
database schema pattern.
-Dan
On 1 Nov 00, at 19:18, Rickard �berg wrote:
> Hi!
>
> Dan OConnor wrote:
> > <spec>Detaching a dependent object that has already been
> > entered into the data source from all of the container managed
> > relationships in which it participates does not cause the persistent
> > representation of the dependent object to be removed. The
> > dependent object will continue to exist in the data store as a
> > detached dependent object. It will not be reachable by navigation
> > but can be accessed by an EJB QL query.</spec>
> >
> > How would this work for the typical one-to-one or one-to-many
> > containment relationship, where the persistent relationship
> > information is part of the object's identity?
>
> Good question. I assume your question relates to how to model the
> relationship in database tables, i.e. if one uses a separate
> relationship table or not. My intuition says that it is not a problem
> really. You can still use table columns for such relationships.
>
> Do you have a particular case which you think will be problematic? Can
> you outline what the problems would be?
>
> regards,
> Rickard
>
>
>
