On Tue, 2003-04-08 at 01:22, Michael Schuldt wrote:
> Hi,
>
> I'm wondering about something like a commit-problem.
>
> I've got two classes:
>
> class TbUser:
> ID
> NAME
> LOGIN
> PWD
>
>
> class TbOffer:
> ID
> NAME
> PRICE
> AMOUNT
> USER_ID
>
>
>
> From out the classes you can see, that there's a 1:n relation btw. TbUser
> and TbOffer.
>
> In my application I'm creating a new TbOffer, filling the attributes and
> connect it to a former read user by calling:
>
> newOffer.setBelongsToUser (formerReadUser);
>
>
> At the end I'm calling theContenxt.commitChanges ()
>
>
> Everything works perfect. The relation is done and in another part of my
> application I'll get a list of all Offers belonging to one User. The user
> was read from the database. Even the new created Offer is in the List.
>
> But on my surface I try to print out all information from TbOffer and
> there's a null in the USER_ID. This will stay until I'll end the session.
> I'm only able to get the ID by reading the User fromout the offer again. Is
> there an error? It's important to me to get the ID but because of speed I
> don't want to read every user for each offer again and again! I just want to
> have the USER_ID?
Certainly that's how I'd expect it to work, if you're trying to get
USER_ID from the committed snapshot
(DataObject.getCommittedSnapshot()).
If you're calling getCurrentSnapshot() then I'd expect you to see
USER_ID and if you're not then that's an interesting case (might be a
bug). However, there is generally very little call for using the
snapshot to get foreign key values.
Would it not be easier to simply read the belongsToUser property to get
back to the User? e.g
TbUser aUser=anOffer.getBelongsToUser();
This will transparently fetch the user, but only if hasn't already been
fetched. If you then still *really* need to get the USER_ID, you can
get it from the ObjectId of aUser:
Integer
userId=(Integer)aUser.getObjectId().getIdSnapshot().get("USER_ID");
Does this help, or have I missed your point?
Craig Miskell
This archive was generated by hypermail 2.0.0 : Mon Apr 07 2003 - 16:03:49 EDT