openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: Circular Dependencies and Bidirectional Relationships
Date Fri, 03 Aug 2007 19:15:58 GMT
> The tricky part is managing the Java relationships. Currently, JPA
> requires that the object model be consistent in memory before you
> commit. Which means that you need to do both: author.books.add
> (newBook) and newBook.authors.add(author) before committing.
> Similarly, you need to do both publisher.magazines.add(newMag) and
> newMag.publisher=publisher.

Note that OpenJPA has extension features that allow a bidirectional
relationship to be automatically maintained. However, my preference is
for the object model to maintain itself correctly, which typically
means creating public mutators and accessors rather than directly
exposing the collection instances. I prefer this because in such an
environment, your object model will behave the same whether or not
you're using JPA at the moment, which I think is a useful goal.

-Patrick

On 8/3/07, Craig L Russell <Craig.Russell@sun.com> wrote:
> Hi Geoffrey,
>
> The two cases below are handled naturally as part of ORM. While they
> are circular relationships in the Java object model, they are not
> circular in the schema.
>
> My experience is that best practice does not exclude circular
> references among classes *in the same package*. Circularity among
> classes in different packages is a separate issue.
>
> For the Book/Author relationship, a join table is used to associate
> books with authors. The collection on both sides is mapped to the
> join table. The join table contains two columns, one that is a
> foreign key to Book and the other a foreign key to Author.
>
> For the Publisher/Magazine relationship, a foreign key in Magazine
> refers to the Publisher, and this foreign key is also used to map the
> Collection<Magazines> field of Publisher.
>
> The tricky part is managing the Java relationships. Currently, JPA
> requires that the object model be consistent in memory before you
> commit. Which means that you need to do both: author.books.add
> (newBook) and newBook.authors.add(author) before committing.
> Similarly, you need to do both publisher.magazines.add(newMag) and
> newMag.publisher=publisher.
>
> Hope this helps,
>
> Craig
>
> On Aug 3, 2007, at 10:21 AM, Geoffrey Downs wrote:
>
> >
> >
> >
> >
> >
> > Hi all,
> >   I have a question concerning best practices for implementing
> > bidirectional relationships in openJPA. I am working on a new
> > development
> > project that is evaluating using openJPA as our ORM solution.
> > Architectural
> > coherence is fundamentally important to the project, so we'd like
> > to avoid
> > circular dependencies in our java classes whenever possible. My
> > question
> > is: how do we avoid circular dependencies when dealing with
> > bidirectional
> > or containment relationships in openJPA?
> >
> > For example: consider the Book-Author relationship (many-to-many,
> > bidirectional). The corresponding Java classes might look something
> > like:
> >
> >    class Book{
> >       private Collection<Author> authors;
> >       ...
> >    }
> >    class Author{
> >       private Collection<Book> books;
> >       ...
> >    }
> >
> > Unfortunately, this means that the class Book depends on the class
> > Author,
> > and that the class Author also depends on the class Book. Has anyone
> > developed a best-practice for how to circumvent this? Perhaps
> > creating a
> > BookAuthor relationship class would be a viable option? How would
> > this work
> > within the context of openJPA's features like dirty checking,
> > cascades,
> > etc.?
> >
> > Example: consider a containment relationship, such as the
> > Magazine-Publisher relation (Publishers have multiple magazines, every
> > magazine has exactly one publisher). The corresponding Java classes
> > might
> > look like:
> >
> >    class Magazine{
> >       private Publisher publisher;
> >       ...
> >    }
> >    class Publisher{
> >       private Collection<Magazine> magazines;
> >       ...
> >    }
> >
> > Again, this introduces a circular dependency between the Magazine and
> > Publisher classes. We could remove this circular dependency by
> > asserting
> > that the Magazine class should not know about it's parent Publisher
> > instance. However, this would result in a database schema that did not
> > reflect reality: we could easily create "orphaned" magazine objects
> > that
> > had no association with a publisher object.
> >
> > Any thoughts on how to resolve these issues would be creatly
> > appreciated.
> >
> > Thanks,
> > -Geoff Downs
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>


-- 
Patrick Linskey
202 669 5907

Mime
View raw message