openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Downs <down...@us.ibm.com>
Subject Re: Circular Dependencies and Bidirectional Relationships
Date Fri, 03 Aug 2007 18:53:51 GMT





Thanks Patrick,

One more question:


> > 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.
>
> You can specify cascade-delete and foreign key cascade behavior on
> unidirectional relationships, so the model should remain consistent.

Maybe I am not specifying the metadata correctly, but when I am hitting a
scenario where I remove a "magazine" object from the containing "publisher"
object's list (in the context of a transaction) and commit the change.
Returning to the database, I see that the Publisher_Magazine relationship
table has been updated, so subsequent retrievals of the publisher object no
longer refer to the magazine child. The Magazine table, however, still
contains the record for the object that I removed from it's parent.

My metadata on the Publisher's "magazine" property looks like this:

   class Test{
      private List<TestChild> testChild = new ArrayList<TestChild>();

      @OneToMany(fetch=FetchType.EAGER,cascade={CascadeType.ALL},
                        targetEntity=styx.test.TestChild.class)
      //@InverseLogical("parent")
      public List<TestChild> getTestChild() {
            return testChild;
      }
      ...
   }

My test code performs these actions:
   Begin transaction
   retrieve "Test" object (i.e. 'Publisher' object)
   test.getTestChild().clear();
   Commit transaction

The behavior I *want* in this scenario is that the publisher (test) object
no longer refer to the magazine (testChild) object, and also that the
magazine object (testChild) be removed from the database. This is not
happening. Any thoughts on what I'm missing here? Your previous email made
it sound like this behavior could be achieved automatically through the
openJPA metadata.

Thanks again,
-Geoff

>
> -Patrick
>
> On 8/3/07, Geoffrey Downs <downsgs@us.ibm.com> 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
>
>
> --
> Patrick Linskey
> 202 669 5907
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message