From dev-return-9532-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Wed Nov 19 15:21:08 2008 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 54658 invoked from network); 19 Nov 2008 15:21:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 Nov 2008 15:21:08 -0000 Received: (qmail 1044 invoked by uid 500); 19 Nov 2008 15:21:16 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 946 invoked by uid 500); 19 Nov 2008 15:21:15 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 932 invoked by uid 99); 19 Nov 2008 15:21:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Nov 2008 07:21:15 -0800 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=SPF_HELO_PASS,SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lists+1214986235816-210739@n2.nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Nov 2008 15:19:52 +0000 Received: from tervel.nabble.com ([192.168.236.150]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1L2or6-0003Rj-B3 for dev@openjpa.apache.org; Wed, 19 Nov 2008 07:20:36 -0800 Message-ID: <1227108036336-1519426.post@n2.nabble.com> Date: Wed, 19 Nov 2008 07:20:36 -0800 (PST) From: Yuri To: dev@openjpa.apache.org Subject: Re: Extend Mapping classes or implement custom strategies? In-Reply-To: <1227082991382-1518264.post@n2.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: ydewit@gmail.com References: <1227075711921-1518056.post@n2.nabble.com> <1227082991382-1518264.post@n2.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org That makes me think whether using a custom VersionStrategy could be what I need. Adding temporality to a persistent class does affect version and I also see that StateManager already has a _version field where I could store a custom Version instance that holds for the validStart and validEnd. Here I am assuming that VersionStrategy.map() can then synthetically add the validEnd, validStart field mappings to ClassMapping and adjust primary key and unique constraint. Humm, I guess it would still make more sense to have a single @Temporal annotation at the class level that would setup the ClassMapping, FieldMappings and the proper version strategy otherwise the user would have to declare a version field with a specific Version object. I still need to figure out how to add a new custom annotation and override the default strategies with temporal ones. Can ProductDerivation help in any way here or should I stay away from it? I was gong the nuclear path of extending ProductDerivation, Configuration, MappingRepository, ClassMapping, etc, etc. thanks for you help! -- yuri Pinaki Poddar wrote: > > Hi, > An analogous usage is VersionStrategy. > May be you should also refer to Custom Field Mapping [1] > Adding extra temporal data to every instance is most likely can be > accomplished by adding extra field mapping to an annotated class. So > effectively the annotation should result in adding extra field mapping to > ClassMapping. Then the user need not to declare fields for the temporal > state. > > [1] > http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_mapping_custom_field > > > -- View this message in context: http://n2.nabble.com/Extend-Mapping-classes-or-implement-custom-strategies--tp1518056p1519426.html Sent from the OpenJPA Developers mailing list archive at Nabble.com.