i checked in the bug fix. referenced obj may now be a proxy.
hth jakob
Jakob Braeuchi wrote:
hi bonnie,
it is a bug :(
see http://scarab.werken.com/scarab/issues/id/OJB181
jakob
Jakob Braeuchi wrote:
hi bonnie,
Bonnie MacKellar wrote:
that's true ojb materialized the real object behind the proxy but the payer still references the proxy.Sure, I understand that the customer returned in my first set of code is a proxy. But I thought that when I traverse the link, the entire object is retrieved.
it may be a bug :(It certainly behaves that way. I can print out the name of the customer (part of the full business object) as can be seen from the code. I can also print out the correct customer ID. So why can't OJB take that same customerID value and stuff it in the generated INSERT query? That is what I don't get.
hth
I did not try using a non-proxied reference, but I bet it would work. I am trying to understand why.
thanks,
Bonnie
jakob
-----Original Message----- From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] Sent: Monday, June 16, 2003 4:46 PM To: OJB Users List Subject: Re: confused by behavior of 1:n relationship
hi bonnie,
Bonnie MacKellar wrote:
On Friday, I posted asking about a strange bug in my system.
I never got any
responses, but I did find the cause of the bug. The problem
is, I don't
understand the cause. I was hoping that someone who knows more about relationship and proxy behavior might enlighten me. I really need to understand this so I can not make these mistakes in the future.
I have three classes : User, Customer, and PaymentTxn. At
the point at
which the strange behavior occurred, I had retrieved a user, using a
criteria query, and was creating a PaymentTxn object. The User object
has a reference to a Customer object, which I wanted to use
in my new PaymentTxn object. The User object's reference was specified in the repository_user.xml file like this :
<field-descriptor
name="customerID"
column="customerID"
jdbc-type="INTEGER"
/> <reference-descriptor
name="customer"
class-ref="com.mobius.activebill.persistentobjects.Customer"
proxy="true" >
have you tried to use a non-proxied reference-descriptor ?
<foreignkey field-ref="customerID"/> </reference-descriptor>
The reference in the PaymentTxn object is specified in the same way.
When I tried to get the Customer via the User object by following the
reference, the strange behavior occurred. I could get the
Customer object,
and print out its id properly. But when I tried to add it to the User
object,
the generated SQL got the customer id value wrong. When I changed
the code so that I used a criteria based query to retrieve the
Customer object, the generated SQL was fine. Why? What is
the difference
in behavior? The sequence of retrievals looks the same in
either case.
Here is the code that did not work :
CustomerInterface customer = payer.getCustomer();
System.out.println("customer name is " + customer.getName());
System.out.println("customer id is " + customer.getID());
paymentTxn.setIssuingCustomer(customer); broker.store(paymentTxn);
The name and id printed out correctly, but after calling
setIssuingCustomer,
the associated SQL insert statement had the wrong value (a 0) for customerID.
the customer referenced by payer.getCustomer is actually a proxy !
But this code did work :
CustomerInterface customer =
retrieveCustomerByName("TheBigCustomer");
System.out.println("customer name is " + customer.getName()); System.out.println("customer id is " + customer.getID()); paymentTxn.setIssuingCustomer(customer); broker.store(paymentTxn);
here the customer is a "real" business object (i assume you did not define proxy=true in the class-descriptor)
The only difference is the way in which I obtained the customer. Why should this be different?
thanks, Bonnie MacKellar software engineer Mobius Management Systems, Inc. [EMAIL PROTECTED]
hth
jakob
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
