openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dick <michael.d.d...@gmail.com>
Subject Re: Evicting
Date Tue, 08 Feb 2011 21:27:22 GMT
On Tue, Feb 8, 2011 at 2:02 PM, Daryl Stultz <daryl.stultz@opentempo.com>wrote:

> On Tue, Feb 8, 2011 at 2:33 PM, Michael Dick <michael.d.dick@gmail.com
> >wrote:
>
> > Out of idle curiosity, why would one insert job1 right away? If you
> needed
> > the objects, but would selectively commit a subset of them, couldn't you
> > just create the POJO and merge later?
> >
> > Or does insertJob start and complete its own transaction?
> >
> > This is just the way I create objects for unit testing. What's actually
> happening is that some old JDBC inserts the records then I find() them with
> an EM. So you can think of them as already existing. You could change the
> first 2 lines from this:
>
> Role job1 = setup.insertJob("XX_1"); // instantiates and inserts via
> ThreadLocal EM
>
> Role job2 = setup.insertJob("XX_2");
>
>
> to this:
>
> Role job1 = em.find(Role.class, 170);
>
> Role job2 = em.find(Role.class, 171);
>
>
> This would assume they already have been inserted, like a setUp() method of
> a unit test would typically do. This is not a typical scenario for my core
> application, but since the data model is exposed to JavaScript, I don't
> have
> any idea what the crazy script writers might do.
>

Thanks for the explanation.

Here's where I was going. If the inserts were done by JDBC and you're using
a transaction scoped EntityManager then the entities from find wouldn't be
managed. So your merge scenario would work, more or less like you wanted.

But for extended scope EMs the entities will be managed, and you're out of
luck. At least with OpenJPA 1.2.

-mike

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message