Antwort: Correct way to getRelatedObjects with each relatedObject reference to this object?
The only way to achieve this in general would be modifying the object.vm
template which generatates the get${relCol} method.
I would believe that the behaviour you describe would make sense
generally. Any opinions on that from other people ? By doing this one
would increase coupling between objects.
Thomas
> Maybe the subject makes sense. Let me explain.
>
> I have two tables, PURCHASE_ORDER and ITEM. ITEM has a foreign key to
> PRUCHASE_ORDER. Thus, the generated BasePurchaseOrder class has a
> getItems() method that returns all the items associated with a
PurchaseOrder.
>
> I find myself with code in the Item class that needs to work with its
> PurchaseOrder, so it does calls getPurchaseOrder(). The problem is that
> this method loads a new copy (and a new object) from PURCHASE_ORDER.
> I'd rather have a reference to the original PurchaseOrder. Consider
> this code:
>
> PurchaseOrder po = PurchaseOrderPeer.retrieveByPK(poid);
> for (Item item : po.getItems())
> item.doWork();
>
> in Item.doWork():
>
> log.info("I'm part of order "+getPurchaseOrder().getID());
>
> Okay, so log.info may be trivial, but you get the point--the
> getPurchaseOrder() call will create a new object from the database.
>
> Is there a way I can pre-populate the Items' aPurchaseOrder to the
> object I start with (po)?
>
> I know there are some doSelectJoinXXX methods, but they didn't look like
> exactly what I wanted. My straw-man approach is to override getItems as
> in PurchaseOrder as in
>
> @Override
> public List getItems() throws TorqueException
> {
> List items = super.getItems();
>
> for (Item item : items)
> item.setPurchaseOrder(this);
>
> return items;
> }
>
> but this seems tacky to use on every call.
>
> Brendan
>
> -
> To unsubscribe, e-mail: torque-user-unsubscr...@db.apache.org
> For additional commands, e-mail: torque-user-h...@db.apache.org
>
Re: Antwort: Correct way to getRelatedObjects with each relatedObject reference to this object?
Hi Thomas,
as an user / programmer I would expect parent.getChildren().getParent() to
return the original parent object. Thus I would agree that it feels natural to
set the parent of the children upon retrieval of those children.
Regards,
Hidde.
- "Thomas Fischer" wrote:
> The only way to achieve this in general would be modifying the
> object.vm template which generatates the get${relCol} method.
>
> I would believe that the behaviour you describe would make sense
> generally. Any opinions on that from other people ? By doing this one
> would increase coupling between objects.
>
>Thomas
--
Hidde Boonstra
Us Media B.V.
Stadhouderskade 115
1073 AX Amsterdam
t: 020 428 68 68
f: 020 470 69 05
www.usmedia.nl
-
To unsubscribe, e-mail: torque-user-unsubscr...@db.apache.org
For additional commands, e-mail: torque-user-h...@db.apache.org
Re: Antwort: Correct way to getRelatedObjects with each relatedObject reference to this object?
Thomas Fischer wrote:
> The only way to achieve this in general would be modifying the object.vm
> template which generatates the get${relCol} method.
>
> I would believe that the behaviour you describe would make sense
> generally. Any opinions on that from other people ? By doing this one
> would increase coupling between objects.
>
The method add${relCol} already does this. So there will be no more
coupling than before. I agree that all these items should have a
reference to the same purchase order instance. The fix would require
another loop, however, which slows down these methods considerably.
The getItemsJoinPurchaseOrder()-method also creates a new copy of
PurchaseOrder for every line of Item. This is something I wanted to
address in 4.0 anyway.
Bye, Thomas.
-
To unsubscribe, e-mail: torque-user-unsubscr...@db.apache.org
For additional commands, e-mail: torque-user-h...@db.apache.org
Re: Antwort: Correct way to getRelatedObjects with each relatedObject reference to this object?
Thomas Vandahl wrote: > The getItemsJoinPurchaseOrder()-method also creates a new copy of > PurchaseOrder for every line of Item. This is something I wanted to > address in 4.0 anyway. Just one additional comment: Torque doesn't care much how many object copies of the same database record exist in memory. I think this should be addressed in 4.0 because it may cause inconsistencies. As has been discussed before this may require the introduction of some kind of session or context object. Bye, Thomas. - To unsubscribe, e-mail: torque-user-unsubscr...@db.apache.org For additional commands, e-mail: torque-user-h...@db.apache.org
