Mailing-List: contact users-help@openejb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openejb.apache.org
Received-SPF: pass (athena.apache.org: domain of saintx.opensource@gmail.com
 designates 74.125.46.31 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=dDcl/Id9+oJtDwDJ6OhapItVPT3TnhE3YFO57BNkumhyO4ajYdc2PQclKYPDMAx/WBrI/RINeiZ9QsEUrlZtGl+iMmMJziL+shTw8JgmuG55HP2dO6Ane/If7/LSu7eiv09rR5W21bnnsLysyCX4tk/4Uo0K8fyeCFwLET0m/OQ=
Message-ID: <b0a94a6d0804211839p474d9259t47553a00eaea76d3@mail.gmail.com>
Date: Mon, 21 Apr 2008 20:39:18 -0500
From: "Alexander Saint Croix" <saintx.opensource@gmail.com>
To: users@openejb.apache.org
Subject: Re: Best practice for cascading persist of existing entity records
In-Reply-To: <8C1EEC57-C062-41C8-A219-2D3B2AE08102@iq80.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_11324_883846.1208828358256"
References: <b0a94a6d0804200857p6b2ae7a1wa79ca03e66e7265c@mail.gmail.com>
	 <8C1EEC57-C062-41C8-A219-2D3B2AE08102@iq80.com>

------=_Part_11324_883846.1208828358256
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks for the help, man.  I appreciate it.  The good news is that I don't
have multiple instances of units with the same values.  I use a static
factory to build units (such as kilogram), and make them available via
public static references from an SI class.

Forgetting units for a moment, let's say I have two entities.  Person and
Cheese.  I provide a static reference "Cheeses.SWISS" to a pre-built
instance of Cheese with the "name" field of the instance set to "swiss".
Then, I create Person bob = new Person("Bob", Cheeses.SWISS) and call
mgr.persist(bob).

In my case, I've got a cascading PERSIST relationship between Person and
Cheese.  So, after the transaction, Cheeses.SWISS has an ID value.

Now, if I create Person alex = new Person("Alex", Cheeses.SWISS) and pass it
to mgr.persist(alex), I get a funny error about the primary key field
already having a value (sorry, I don't have the exact error text, but it's
easy to reproduce if it comes to that).

I gather from this that this isn't the best way to introduce new objects to
the persistence store when the objects reference data that is already in the
store.  I'm guessing that instead of this, there should be some kind of
transaction that gets the Cheese object from the datastore and then adds a
reference to it to the new Person object.  I think that pre-loading the SI
units into the datastore at the beginning makes a lot of sense.  Now I just
need some way to make sure that new entities that reference data already in
the datastore are correctly wired.  I'm wondering if there are examples of
this sort of thing?

Cheers,
--
Alex


On Mon, Apr 21, 2008 at 12:21 PM, Dain Sundstrom <dain@iq80.com> wrote:

> I'm not sure I fully understand what you are running into, but I'll take a
> stab at it.
>
> Normally, I suggest people avoid storing unit tables in the db, but in
> your specific case, I know you are have a persistence model for a truly
> generic system.  BUT, for anyone else reading this email in the archives, be
> careful with unit tables as you can get nasty locking problems.
>
> In your case, I would suggest, if at all possible, that you create and
> cache your unit objects in a separate "setup" transaction.  After the setup
> transaction, no one would add new units (in a production system valid units
> would be added by hand by an admin), so you would never have a cascade
> persist problem.
>
> As for your exact situation, I think the root cause of the problem is that
> you have multiple instances with the same value, say kilogram, in your
> object graph.  If instead all references refereed to the same object
> instance, you the key would only be generated once.  To test my theory,
> replace the Unit constructor with a static factory, and cache the instances
> you return.
>
> -dain
>
>
> On Apr 20, 2008, at 8:57 AM, Alexander Saint Croix wrote:
>
> > Howdy, all.
> >
> > I'm wondering what the best practice is for the following use case:
> >
> > I have a handful of entity classes, one of which is a Unit (such as
> > "kilogram") which has an auto-generated UID field.  Each individual
> > instance
> > of Unit ("kilogram", "second", "ampere", etc) can and will be used by
> > multiple instances of the other entity classes.
> >
> > The problem arises after I persist one of the unit instances (such as
> > "kilogram") and it is assigned a primary key field generated by the
> > container.  From that point forward, each other object that refers to
> > that
> > specific Unit instance gives me trouble when I try to persist it,
> > because it
> > already has a nonzero UID field value.
> >
> > Ideally, I do not want to have more than one "kilogram" record in the
> > "Unit"
> > table.  Is there a common practice to tell the persistence container to
> > "apply the persist cascade of the holding object to this field, unless
> > the
> > data represented by the field already exists in the database, in which
> > case
> > don't cascade--just reference the UID of that instance"?
> >
> > If the question isn't clear, I can provide sample code.  If you want to
> > punt
> > to the OpenJPA list, that's also acceptable.
> >
> > Cheers,
> > --
> > Alex
> >
>
>

------=_Part_11324_883846.1208828358256--