On Tue, Feb 8, 2011 at 7:49 PM, Craig L Russell <[email protected]>wrote:
> Or have I misunderstood your example below? The key for me is the "not
> logical"
>
>
> assertEquals("XX_newname_1", job1b.getName()); // !!! this is not logical
>> since I didn't "save" job1
>>
>
> Well, reading the code, both job1 and job2 share the same entity manager so
> "begin transaction, save, commit" will save changed instances.
>
Yes, that's what I discovered (not knowing how it worked prior to selecting
JPA as the ORM). This may make perfect sense to someone who knows JPA well
and maybe something about JDO, but I was quite surprised to find it works
this way. I called merge() on job2 so it really doesn't make sense that
changes to job1 are saved.
>
> You don't mention it, but I assume that setName immediately changes the
> state of a Role. So the "save" doesn't really do anything.
>
The "save" is where a transaction is opened and committed (and job2 is
merged).
>
> If you want to isolate changes to job1 and job2 you would have to buffer
> changes (e.g. setName) and only apply them when performing the save.
>
I am the developer of the core Java code of my application. I can deal with
issues like this when I have to, but I have people on staff writing
JavaScript extensions to the product who know nothing about how JPA works
and ideally shouldn't have to.
>
> I also don't quite understand what you are trying to accomplish with:
>
> deleteViaJdbc(job1b);
>>
>
> Is this intended to simulate a third party deleting data that you're using?
> If so, then the observed behavior seems rational.
>
It's simulating a legacy routine to delete data.
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
http://www.opentempo.com
mailto:[email protected]
