Hi Madhu,

I assume that with the suggested changes to your persistent classes,
the only issue is with the setAddressId method? Would it be possible
to implement this as a no-op?

Craig

On Aug 13, 2008, at 10:28 AM, Madhu Kalaimalai wrote:

>
> Hi Craig
>
> Thanks for the reply.
>
> The way the old code works is first persist the address and then get
> the id
> of the address, create the phone object and set the adress id as the
> fk ie
> setAddrId which is mapped to the ADDR_FK_ID of the PHONE table as
> below
> Address address = new Address();
> address.setAddrTypeId(67548);
> address.setCountry("USA");
> em.persist(address);
> em.flush();
> Phone newPhone = new Phone();
> newPhone.setTelphoneNum("99999");
> newPhone.setIntlPhoneInd("Y");
> newPhone.setPhoneTypeId(65093);
> newPhone.setPrimaryNumInd("Y");
> newPhone.setAddressId(address.getAddrId());
> em.persist(newPhone);
>
> The existing code is huge, we don't want to refactor.
>
> In the new case, we are not doing any mapping of the addressId and
> using the
> Address object to map
> to addressId. Your point of getAddressId getting the reference of
> Address is
> good.
>
> How do we make the above code work with the new mapping ie how do
> we make
> the setAddresId impl to work for the new mapping ?
>
> If needed i can send the sample code.
>
> Rgds
> Madhu
>
>
>
>
> Craig L Russell wrote:
>>
>> I know I'm jumping into this issue late, but here goes:
>>
>> In order for OpenJPA to manage the relationships, you need to define
>> the association between the classes by using the mappedBy="address"
>> notation on Address.phones. This way, OpenJPA knows about the
>> bidirectionality of the relationship and knows to populate both sides
>> to be consistent.
>>
>> In order to return the addressId, you need to use the getId method of
>> address and not persist the addressId separate from the relationship,
>> or have a separate addressId field.
>>
>> So, I'd think this would work:
>>
>> class Phone {
>> public Long getAddressId()
>> {
>> return this.address.getId();
>> }
>>
>> Basically, if you eagerly fetch Address, the Id will be available.
>>
>> Then, as Pinaki said earlier, the only thing you might need to do to
>> make the getAddressId valid is to flush the relationship. Then the
>> code that depends on the relationship will still work after the
>> create
>> transaction is either flushed or committed.
>>
>> Craig
>>
>> On Aug 12, 2008, at 3:35 PM, Madhu Kalaimalai wrote:
>>
>>>
>>> Hi Pinaki
>>>
>>> The id is generated through the oracle sequence, so the id is not
>>> know till
>>> the SQLs are generated.
>>>
>>> The problem being having the addrId and Address having mapped to the
>>> one
>>> column ADDR_FK_ID of the Phone table as we wanted the old way of
>>> using the
>>> AddrId and new way of Address to work.
>>>
>>> When i do the one direction from Address to Phone, it says we are
>>> trying to
>>> set two different values to same object. For this case for the
>>> AddrId column
>>> mapping it sets null and for the Address mapping it sets the Address
>>> primary
>>> key.
>>>
>>> When I do the bidirectional mapping, the insert statements to Phone
>>> has
>>> addrId columns twice one for the AddrId and other for Address. It
>>> says the
>>> duplicate column in the insert statement.
>>>
>>> I am looking at the possibility of POJOs supporting the old and new
>>> way of
>>> persistence.
>>>
>>> Hope you got what i am trying to explain.
>>>
>>> Rgds
>>> Madhu
>>>
>>>
>>>
>>> Pinaki Poddar wrote:
>>>>
>>>> Hi,
>>>> The mapping you described originally in this post should work as
>>>> well.
>>>> Of course, the application must set the values of ADDR_FK_ID from
>>>> both
>>>> sides consistently.
>>>> For example, if there is one Address instance A1 with id 12345 and
>>>> A1.phones is a Set that contains two Phone instances P1 and P2.
>>>> Then the
>>>> application must ensure that for both P1 and P2 addressId field is
>>>> set to
>>>> 12345 before commit. The problem will be complicated only if
>>>> Address has
>>>> auto-generated identity.
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/OpenJPA---two-sided-relation-between-objects-Issue-tp687050p720633.html
>>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>>
>>
>> Craig L Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@(protected)
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
>>
>
> --
> View this message in context: http://n2.nabble.com/OpenJPA---two-sided-relation-between-objects-Issue-tp687050p722443.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@(protected)
P.S. A good JDO? O, Gasp!