Marina,
There is nothing in the spec that says your relationships will be set
up automatically. In my opinion, in the absence of anything explicit
saying they will be, people should assume they will not be. If you
believe that is not the case, the best idea is to send feedback to the
spec committee.
Although you may get correct database behavior by setting the
relationship on one side, and relying on the cascade setting to get the
correct information in the database, the actual object model will not be
correct since there is nothing that will add the back pointer to your
actual object.
-Tom
Marina Vatkina wrote:
>Tom Ware wrote:
>
>
>
>>Marina,
>>
>> It is my understanding that regardless of the cascade setting, you
>>have to set both relationships. The EJB 2.1 specification allowed only
>>one side of a relationship to be set, but as I understand it, that has
>>been removed.
>>
>>
>
>The EJB 3.0 spec says in 2.1.7 Entity Relationships:
>
>The owning side of a
>relationship determines the updates to the relationship in the database, as
>described in section 3.2.3.
>
>
>Where 3.2.3 talks about cascade rules:
>
>" For all entities Y referenced by a relationship from X, if the relationship to Y
>has been
>annotated with the cascade element value cascade=PERSIST or cas-cade=
>ALL, the persist operation is applied to Y.
>
>
>
>
>
>> I believe the cascade functionality is not provided as a way to set up
>>your relationships automatically. It just lets you specify the
>>granularity level with which you have to persist.
>>
>>
>
>If all the above rules mean that if cascade option is set on the inverse side,
>the relationships must be set on both sides, the spec needs to say that
>explicitly.
>E.g. GlassFish/TopLink allow it to be set on the Many side and be propagated,
>which might result in a non-portable application if the developer coded to
>the 1st available provider.
>
>If the above rules do not require setting relationships on both sides, it
>needs to be explicit in the spec.
>
>thanks,
>-marina
>
>
>
>>-Tom
>>
>>Marina Vatkina wrote:
>>
>>
>>
>>>Team,
>>>
>>>I've sent this question to persistence alias on Tuesday,
>>>but it never went through. So I'm resending it to both
>>>aliases as I still don't have luck with persistence alias.
>>>
>>>Note: Our current implementation cascades with
>>>a1.getBs().add(b1) but this doesn't eliminate
>>>the original concern that ownership rules seem
>>>to contradict the cascade rules.
>>>
>>>thanks,
>>>-marina
>>>
>>>-------- Original Message --------
>>>Subject: Cascade persist and 1ToMany relationship?
>>>Date: Tue, 22 Nov 2005 10:25:02 -0800
>>>From: Marina Vatkina <marina.vatkina_at_sun.COM>
>>>To: "persistence_at_glassfish.dev.java.net" <persistence_at_glassfish.dev.java.net>
>>>
>>>Team,
>>>
>>>I'm a bit confused about the rules for creating a set of related
>>>instances in the same tx and persisting them using CASCADE=ALL
>>>setting. The relationships are bidirectional and FK-based.
>>>
>>>Let's say I have A with a collection of 'bs', and B with a property 'a'.
>>>
>>>A a1 = new A(...);
>>>B b1 = new B(...);
>>>B b2 = new B(...);
>>>
>>>
>>>
>>>>From which side do I need to set relationships to call em.persist(a1)
>>
>>
>>>and see the magic?
>>>
>>>If I do it from B (b1.setA(a1)), a1 doesn't know about the related instance
>>>to persist it.
>>>
>>>If I do it from A (a1.getBs().add(b1)), then according to the spec, the
>>>relationship
>>>change won't be propagated because the Many side owns the relationship.
>>>
>>>If I set it from all sides, what do I gain as I could just persist all of them
>>>separately - it's the same ammount of code?
>>>
>>>thanks,
>>>-marina
>>>
>>>
>>>
>>>
>>--
>>Tom Ware
>>Principal Software Engineer
>>Oracle Canada Inc.
>>
>>Direct: (613) 783-4598
>>Email: tom.ware_at_oracle.com
>>
>>
>
>
>
--
Tom Ware
Principal Software Engineer
Oracle Canada Inc.
Direct: (613) 783-4598
Email: tom.ware_at_oracle.com