[Objectbridge-developers] Re: OJB Technical Questions & Tutorial #3

[Christian S. <chr...@ne...>]

Hello,

Hope you dont mind that I throw in my few cents here:

> > SUPPORT FOR MAPPING MANY-MANY RELATIONSHIPS
> > Does OJB currently support the mapping of many-to-many
> > relationships?  I
> > didn't see any examples in the tests.  If not, is this planned for an
> > upcoming release?
> >
> You are right, there is no support for m-n relationships. You have to
> decompose it into two 1-n relationships. You have to do this for your
RDBMS
> ER model anyway, so its not such a big problem in my eyes.
> There are some OJB users (marquier et al.) who are thinking of building an
> n-m extension. But right now there are no concrete plans to include such a
> feature.

I dont think the fact that in physical database modeling you decompose N-M
relationships into separate 1-N relationships makes this a less useful
(should I say crucial?) feature fo an O/R modeling tool. After all, it is
the very purpose of the O/R tool to cover the technical details with a more
abstract and intuitive layer. And even if I was going to program plain SQL,
I would use a double join to directly access the final target entity and not
load the rows of the associative table and then proceed from there.

> > ASSIGNING IDENTITY VALUES
> > Some of the object graphs that I will be persisting have
> > dependent/related
> > objects which do not have IDs.  Do all objects have to have IDs when
> > persisting using OJB?  If so, is there a way to have OJB transparently
> > assign IDs using the SequenceManager, without the client code
> > needing to
> > call SequenceManager.getUniqueId() for each object?  If not,
> > can I use a
> > ConversionStrategy as a means of implementing transparent ID
> > assignment?
>
> I'm not sure if I get you right: Your database table have no primary key
> columns? Or do they have non numeric keys? Or do you have compound keys,
> that contain of two or more columns?
>
> OJB does require to have primary keys. But they can be of arbitrary type
> (not only INT) and may also be compound keys.

If I understand Sasha right, He is referring to what in E/R we used to call
identifying relationships. This is where one entity is dependent on another
in such a way that the foreign key becomes part of the primary key. If this
is a 1-1 relationship, there is even no need for an additional identifier,
therefore it should be sufficient to have a foreign key that also serves as
primary key (the primary key is "inherited" by the dependent entity. In
fact, if you implement inheritance on top of a relational model, this is
exactly where you end up, dont you?). It would be rather inconvenient IMO if
the dependent entity had to maintain an additional primary key just for the
sake of the O/R mapping tool.

thanks, and good night,
Christian