From dev-return-20591-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Sun Jun 3 09:12:59 2012 Return-Path: X-Original-To: apmail-openjpa-dev-archive@www.apache.org Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AC2EFC43B for ; Sun, 3 Jun 2012 09:12:59 +0000 (UTC) Received: (qmail 49899 invoked by uid 500); 3 Jun 2012 09:12:59 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 49628 invoked by uid 500); 3 Jun 2012 09:12:54 -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 49585 invoked by uid 99); 3 Jun 2012 09:12:52 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Jun 2012 09:12:52 +0000 X-ASF-Spam-Status: No, hits=3.2 required=5.0 tests=FREEMAIL_FORGED_REPLYTO,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [77.238.189.67] (HELO nm14.bullet.mail.ird.yahoo.com) (77.238.189.67) by apache.org (qpsmtpd/0.29) with SMTP; Sun, 03 Jun 2012 09:12:44 +0000 Received: from [77.238.189.56] by nm14.bullet.mail.ird.yahoo.com with NNFMP; 03 Jun 2012 09:12:22 -0000 Received: from [212.82.108.249] by tm9.bullet.mail.ird.yahoo.com with NNFMP; 03 Jun 2012 09:12:22 -0000 Received: from [127.0.0.1] by omp1014.mail.ird.yahoo.com with NNFMP; 03 Jun 2012 09:12:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 579852.89122.bm@omp1014.mail.ird.yahoo.com Received: (qmail 97694 invoked by uid 60001); 3 Jun 2012 09:12:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s1024; t=1338714742; bh=u9T1oMUuyza5IXEgbTfF+GqiAllJyrrKSMcoZnFw7zk=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BXw9za4A46oACRg5HfX2FD5ywbgUaZjw1k2nENMUdinVXCkU62WoZX1b9zTqxBzf9qFVjjZgx3EGLstXrG09qG/XpzkLQo0S42z4aQv+XBtA3M10tA18I+EaUk1MBZ5eAUFbmfxWZx2IcX1pRdPuv3mOKYpu51tu9FRJBJLndWo= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dog9h9LB1pkyTYDYEk0jMSzv540LhMyMHNV8GvxybL8Vmn7lkJ1WSTz/8R7pxgyuLaKCDjq4HCoJA7UcTmMW4kwCEUYM2GPmNiYnnfdXNflkhy1r1oLdtZslT4oHWoUBzaISTOdtUAEge/HVgz4myi/O4cFTrBX5KPDGeqZuGog=; X-YMail-OSG: u4ctUMAVM1m6X_.AHDQDFwSCkgZnBVLnuh1uVfQkE_LEeT4 tixJTkoFzmaLso65XoW1Rth7LI84DUevTwnWCprVFXslZDkmFurDat5L8JfS kob7jN6mRwtm.fcLmrv9yGVguzHLi2LkBR1J.0yxfhUybDDgqTM6e09hKkfh Vs_685Xykc2yr02LcxhHQRiu6LMmcCMY_7XSjS6ccE9m9FGemkD8yvcuUm2A oEuz3g3hUiOJvGf6JCS04jRSSCoKbXhh8mYrrSAZxcayQYKhpfgNHR2KTUIw OXcVTUz9wq6.yKGyQcZJZVnLgN9KUlXZp36ZKfePDiZ.1vV9mAk8h0n4ilyI 1xC7dn_LTxb6WnsJj_rIta5dlIwU47EYJGPaQABcKpI.fPke2j9jUaJTWV9Z mhXfYqYIQ9S2ekPbHFWGQBhJ.0syOdaygDfArH7bNipgnmXM2BOQ__Ox.kHm vDwV18FVndwvOm3BzPkVBUlfUN6xy53b184l1l5XdpDMQKXOSZVsIWPUZnjp LmSduNSaqfG0- Received: from [80.108.122.184] by web171506.mail.ir2.yahoo.com via HTTP; Sun, 03 Jun 2012 10:12:21 BST X-Mailer: YahooMailWebService/0.8.118.349524 Message-ID: <1338714741.95912.YahooMailNeo@web171506.mail.ir2.yahoo.com> Date: Sun, 3 Jun 2012 10:12:21 +0100 (BST) From: Mark Struberg Reply-To: Mark Struberg Subject: JPA inter-vendor compatibility and the spec To: openjpa-dev MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Hi folks!=0A=0AI remember having talked with one of you in the past why the= following properties are NOT enabled by default:=0A=0A=C2=A0=0A= =C2=A0=0A=0AThis basically tells OpenJPA to a= lso serialise (externalise) the _dirty and _loaded fields along with each e= ntity and restore this info in the DetachedStateManager on de-serialisation= . What I remember is that someone said that this is against the spec. Do yo= u recall which spec paragraph / TCK test this was?=0A=0AThe second option i= s a bit more tricky and deals with out internal handling of proxies when se= rialising. From looking at the source I think the name is a bit confusing. = What it does is to always serialize the whole proxy in any case. Please als= o not that this behaviour was the default in OpenJPA-1.x and only gets chan= ged if your persistence.xml version is "2.0".=0A=0A=0AI basically _always_ = use those 2 magic flags nowadays, because it's the only way you can do seri= alisation without loosing data imo.=0A=0AThere is a little bit of discussio= ns and the pitfalls I had with this options in https://issues.apache.org/ji= ra/browse/OPENJPA-1933=0AIt still doesn't explain why this behaviour was pu= t there initially.=0AThe best source I could find is =0A=0Ahttps://issues.a= pache.org/jira/browse/OPENJPA-1097 and=0Ahttps://issues.apache.org/jira/bro= wse/OPENJPA-968=0A=0AThe best thing explaining this restriction I could fin= d in the JPA spec is:=0A=0A"Serializing entities and merging those entities= back into a persistence context may not be interoperable across vendors wh= en lazy properties or fields and/or relationships are used.=0AA vendor is r= equired to support the serialization and subsequent =0Adeserialization and = merging of detached entity instances (which may =0Acontain lazy properties = or fields and/or relationships that have not =0Abeen fetched) back into a s= eparate JVM instance of that vendor=E2=80=99s =0Aruntime, where both runtim= e instances have access to the entity classes =0Aand any required vendor pe= rsistence implementation classes."=0A=0ABut=C2=A0 reading this again and ag= ain it seems to me that this is _not_ against applying the above properties= by default.=0A=0A=0A=0ADo we still have a bug in there (and we shall fix i= t), or is this area not clearly defined in the spec (and we should aim to g= et it fixed in JPA-2.1)?=0A=0A=0A=0ALieGrue,=0Astrub=0A