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
>
>
>
