Return-Path: Delivered-To: apmail-openjpa-users-archive@minotaur.apache.org Received: (qmail 10882 invoked from network); 24 Sep 2009 16:27:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 24 Sep 2009 16:27:57 -0000 Received: (qmail 89550 invoked by uid 500); 24 Sep 2009 16:27:56 -0000 Delivered-To: apmail-openjpa-users-archive@openjpa.apache.org Received: (qmail 89524 invoked by uid 500); 24 Sep 2009 16:27:56 -0000 Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@openjpa.apache.org Delivered-To: mailing list users@openjpa.apache.org Received: (qmail 89514 invoked by uid 99); 24 Sep 2009 16:27:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Sep 2009 16:27:56 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.223.201] (HELO mail-iw0-f201.google.com) (209.85.223.201) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Sep 2009 16:27:44 +0000 Received: by iwn39 with SMTP id 39so1022371iwn.25 for ; Thu, 24 Sep 2009 09:27:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.75.5 with SMTP id x5mr307119wfa.197.1253809643180; Thu, 24 Sep 2009 09:27:23 -0700 (PDT) Date: Thu, 24 Sep 2009 09:27:23 -0700 Message-ID: <1ba389ce0909240927j5eac2c96t87590e86bb3d3962@mail.gmail.com> Subject: Persistent interfaces enhancement From: matthew To: users@openjpa.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Hi all, I wanted to see what it would take to enhance the support for persistent fields of an interface type. Currently, OpenJPA stringifies the object id of the instance being stored, rendering the relation unqueriable. If this could be enhanced to support the fairly common use case (IMHO) of entities that use single field identity, the id value and type information could be separated and stored in two columns. This would make it possible to query through the relationship predictably. I forsee the types of the columns being string, so as to support any stringifiable single field identity value and a type. One possible implementation that puts all of this info in one place could be this: // Some class that has a persistent interface field public class Calendar { // ... @PersistentInterface({ @PersistentInterfaceImpl(discriminatorValue="MEETING", clazz=Meeting.class), @PersistentInterfaceImpl(discriminatorValue="APPOINTMENT", clazz=Appointment.class) }) protected Schedulable schedulable; } In this manner, queries across persistent interfaces becomes a bit more predictable and, probably more importantly, the storage of an interface type becomes much more palatable to a DBA. A stringified version of the object id, which includes its Java class information, is certainly not something many DBAs would like. Thoughts? -matthew -- mailto:matthew@matthewadams.me skype:matthewadams12 yahoo:matthewadams aol:matthewadams12 google-talk:matthewadams12@gmail.com msn:matthew@matthewadams.me http://matthewadams.me http://www.linkedin.com/in/matthewadams