Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Date: Thu, 22 Sep 2011 09:29:18 -0700 (PDT)
From: Pinaki Poddar <ppoddar@apache.org>
To: users@openjpa.apache.org
Message-ID: <1316708958347-6820960.post@n2.nabble.com>
In-Reply-To: <001201cc7940$d8c7c3a0$8a574ae0$@spiro@dcs-caesar.de>
References: <000001cc78fd$208ef300$61acd900$@spiro@dcs-caesar.de>
 <1316704155094-6820601.post@n2.nabble.com>
 <001201cc7940$d8c7c3a0$8a574ae0$@spiro@dcs-caesar.de>
Subject: Re: AW: Diamond model and foreign keys
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,
  > a solution similar to b) (with Object as a part of EmbeddedKey) was
implemented in my original project as the error first occured.

  Why made you change that model?

> rather strange that OpenJPA makes everything correct having less
> information
  It is not strange. When it has duplicate info and no knowledge of that
they are duplicate, it gets confused. If there is only one piece of
information and no duplicate -- no confusion.

> the duplicate mapping comes from the OpenJPA reverse mapping tool.
I noticed that. But here is a deeper chasm. In relational database
references are inherently bi-directional i.e. a foreign key represents a
bi-directional relation. In Java world, all references are uni-directional.
The code has to ensure the semantics of referential consistency. That deep
chasm is what ORM "tries" to bridge, and fails at times as you may have
noticed :)

-----
Pinaki Poddar
Chair, Apache OpenJPA Project
--
View this message in context: http://openjpa.208410.n2.nabble.com/Diamond-model-and-foreign-keys-tp6819272p6820960.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.