From dev-return-18067-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Mon Nov 29 22:47:28 2010 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 93458 invoked from network); 29 Nov 2010 22:47:28 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 29 Nov 2010 22:47:28 -0000 Received: (qmail 22461 invoked by uid 500); 29 Nov 2010 22:47:28 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 22440 invoked by uid 500); 29 Nov 2010 22:47:28 -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 22432 invoked by uid 99); 29 Nov 2010 22:47:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Nov 2010 22:47:28 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [217.146.183.232] (HELO nm5-vm0.bullet.mail.ukl.yahoo.com) (217.146.183.232) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 29 Nov 2010 22:47:18 +0000 Received: from [217.146.183.216] by nm5.bullet.mail.ukl.yahoo.com with NNFMP; 29 Nov 2010 22:46:57 -0000 Received: from [217.146.183.32] by tm9.bullet.mail.ukl.yahoo.com with NNFMP; 29 Nov 2010 22:46:57 -0000 Received: from [127.0.0.1] by omp1021.mail.ukl.yahoo.com with NNFMP; 29 Nov 2010 22:46:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 581617.57182.bm@omp1021.mail.ukl.yahoo.com Received: (qmail 98925 invoked by uid 60001); 29 Nov 2010 22:46:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s1024; t=1291070817; bh=czkLGe06/vct0nRlcmhEdCMnIx9JtDoHuJH5EQvxB5g=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QNGKFY5EgWqhEQtpTzImms/pfL5gnTtgVgqBfFReLQLbpdVEg1QCgckzjWrr6QqBDrVcoi+CeyysSSxRPGGmaCbAmXrtHWt/f1KgnhiSQFGYNNC8AsiD5V+GEOX56/1RRAm06FIcwRQFzgo2SapDrb+Q3DiChSqk7TfxVyGQ0SE= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KGL33B+5ZjRSd/zMYFgGXqess4f/wI79XWk8ncEy2o13j/1ZjdThoTVrIREd/wWqqhQ/Q6j82eFR2cSTUgMgK9+cSi59UC+HExZFClEsiF/o0D9aLHi0ZsHUjZouXDd9u6gu/kSl6t0RLyc4780QfgURdlPApIr6LA1EXTuHeBs=; Message-ID: <463291.98305.qm@web27804.mail.ukl.yahoo.com> X-YMail-OSG: mBZyN4cVM1kYWZyaiL5psF6p.W5_G8Y.dVOqRxPp_Eu332r PZcRUuk_cEYeQxCgF7.NOfb0qtanFcqzvMGe6W0W1xXrNEwllA7IEBl2TeAT s1XKuK5XJ4gdV8oeks_zSMCuXMnjpTgNgw2Adx1NT5OMkVXd60l.laIgPq_i UckT0Lae5DBDFlLtl.xRnHIymX31FtWhX2e5_XEHVB5rhd9xAQEGlnAkK1_6 cbhkAR2p_KAsrsQDbcqE5icgwM7x_tjnrvTfUmL3umYSVhl0QkJlOLlK9Xn7 DEtb2d9Kc8xNaXUDHm3CVyffs0vqpIaF.n5wy9FSPUCuNRwnF138qUf2CRh0 0kiHFYEmUIsiAyAGX6Q-- Received: from [80.108.118.219] by web27804.mail.ukl.yahoo.com via HTTP; Mon, 29 Nov 2010 22:46:57 GMT X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Mon, 29 Nov 2010 22:46:57 +0000 (GMT) From: Mark Struberg Subject: Re: AttachStrategy Question To: dev@openjpa.apache.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Hi Michael! Txs 4 the quick response! Yea, you got this scenario right, I detach first (in one request), and then= I set the entity before doing the merge (JSF postback in the 2nd request).= I took care that no serialisation is involved (using CODI @ViewAccessScope= d and not the JSF ViewMap), so the detached state information should remain= intact. I'm currently building the latest from trunk and will try to reproduce the = behaviour in unit tests tomorrow morning. txs and LieGrue, strub --- On Mon, 11/29/10, Michael Dick wrote: > From: Michael Dick > Subject: Re: AttachStrategy Question > To: dev@openjpa.apache.org > Date: Monday, November 29, 2010, 8:54 PM > Re-read your original email, and this > makes more sense now. >=20 > I think what's happening is that you're detaching, setting > a field to null, > and then merging the entity into a persistence context. > When you flush to > the database the field that you set to null is not saved > (any other changed > fields would be though). >=20 > This happens because OpenJPA makes some assumptions at > attach time, based on > your DetachState. If it's 'loaded' (the default) we assume > that any null > fields were never loaded from the database. If it's 'fgs' > we check the fetch > group to see whether the field _should_ have been loaded - > if so we'll > assume the value has been changed and write it to the > database, if the field > would not have been loaded in the current fetch group then > we'll ignore > (just like with loaded). If the detachState is set to 'all' > then whatever is > in the entity is written to the database (I think - I've > never tried this > path). >=20 > You're right - the information as to whether the field has > ever been loaded > should be available in most cases - and should be available > in the detached > state field (assuming one is available). I was under the > impression OpenJPA > did check the detached state field before falling into the > AttachStrategy > code (might need to take another look though). >=20 > At any rate, a testcase will definitely help, or if I've > guessed wrong about > the failing scenario let us know.. >=20 > -mike >=20 > On Mon, Nov 29, 2010 at 2:38 PM, Michael Dick w= rote: >=20 > > Hi Mark, > > > > I'm not sure exactly what you're doing to cause the > error, a unit test > > would definitely help there. > > > > The openjpa.DetachState property is a way to specify > which fields will be > > present when an entity is detached. Using a different > DetachState value may > > result in different results depending on your > fetch-group and usage pattern. > > In either case I don't think a field would be reset to > null at detach time > > though. > > > > Maybe I've misunderstood your scenario though. > > > > -mike > > > > > > On Fri, Nov 26, 2010 at 11:51 AM, Mark Struberg > wrote: > > > >> a side note: it works if I use > >> value=3D"fetch-groups"/> > >> > >> But it looks most likely as a bug to me because I > don't serialize the > >> detached entity, nor do I invoke native queries to > get it, etc - just plain > >> JPA! So it must give me exactly the same results > regardless of the detach > >> strategy I use... > >> > >> Should I file a JIRA? > >> > >> LieGrue, > >> strub > >> > >> --- On Fri, 11/26/10, Mark Struberg > wrote: > >> > >> > From: Mark Struberg > >> > Subject: AttachStrategy Question > >> > To: dev@openjpa.apache.org > >> > Date: Friday, November 26, 2010, 4:54 PM > >> > Hi folks! > >> > > >> > I have a question regarding OpenJPA-2.0.1 > AttachStrategy > >> > DETACH_LOADED. > >> > > >> > I have an entity with a Date field. This > field gets filled > >> > with the current date and stored to the > database. Afterwards > >> > it gets loaded from the database and > detached. In the next > >> > request the date will be reset to null. And > here comes the > >> > problem (around AttachStrategy#178): > >> > > >> > > >> >=A0 =A0 =A0 =A0 =A0 > =A0=A0=A0case > >> > JavaTypes.OBJECT: > >> >=A0 =A0 =A0 =A0 =A0 > =A0=A0=A0case > >> > JavaTypes.OID: > >> >=A0 =A0 =A0 =A0 =A0 > =A0=A0=A0case > >> > JavaTypes.ENUM: > >> >=A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0=A0=A0val > >> > =3D fetchObjectField(i); > >> > --->=A0 =A0 =A0 =A0 =A0 > =A0 if (val =3D=3D > >> > null && !nullLoaded) <-- problem > >> > > >> >=A0 =A0=A0=A0return false; > >> > > >> > sm.settingObjectField(into, i, > sm.fetchObjectField(i), val, > >> > > >> >=A0 =A0=A0=A0set); > >> > > >> > break; > >> > > >> > This leads to not getting the date field > reset to null in > >> > the database while merging the entity. > >> > > >> > Imo this should only be skipped if the field > didn't got > >> > loaded previously from the database. I bet > this information > >> > is available, but where can I get this > information from? > >> > > >> > Are some bells ringing, or should I try to > craft a unit > >> > test? > >> > > >> > txs and LieGrue, > >> > strub > >> > > >> > > >> > > >> > > >> > > >> > >> > >> > >> > > > =0A=0A=0A