Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 25844 invoked from network); 7 May 2009 16:48:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 7 May 2009 16:48:33 -0000 Received: (qmail 8667 invoked by uid 500); 7 May 2009 16:48:33 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 8657 invoked by uid 99); 7 May 2009 16:48:33 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 May 2009 16:48:33 +0000 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [212.159.7.36] (HELO relay.ptn-ipout02.plus.net) (212.159.7.36) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 May 2009 16:48:21 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGOtAkrUnw4U/2dsb2JhbADRXoQDBQ Received: from pih-relay08.plus.net ([212.159.14.20]) by relay.ptn-ipout02.plus.net with ESMTP; 07 May 2009 17:48:00 +0100 Received: from [87.114.17.11] (helo=[192.168.0.22]) by pih-relay08.plus.net with esmtp (Exim) id 1M26lL-0006MV-RD for jdo-dev@db.apache.org; Thu, 07 May 2009 17:47:59 +0100 From: Andy Jefferson To: jdo-dev@db.apache.org Subject: Re: Detecting inconsistencies of mapped-by declarations? Date: Thu, 7 May 2009 17:47:59 +0100 User-Agent: KMail/1.9.6 References: <4A030E12.3070505@artnology.com> In-Reply-To: <4A030E12.3070505@artnology.com> Organization: DataNucleus MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905071747.59404.andy@datanucleus.org> X-Plusnet-Relay: 5da882b3149a4c322bb6d40a203315fb X-Virus-Checked: Checked by ClamAV on apache.org > Should the implementation throw an error in such situations, warning the > user of the erroneous metadata? Shared FK relations are a perfectly valid thing to have IMHO http://www.datanucleus.org/products/accessplatform_1_1/jdo/orm/one_to_many_collection.html#shared_fk You could have the same as that example with 1-1 and a discriminator for determining the relation. The place of an ORM spec is to standardise particular relation types, not to prevent other ones. -- Andy (DataNucleus - http://www.datanucleus.org)