Not sure if your template is the same as mine, but for me, both methods do the
EXACT SAME thing when
er.extensions.ERXEnterpriseObject.updateInverseRelationships property is set to
true. ( @see
er.extensions.eof.ERXGenericRecord.InverseRelationshipUpdater.updateInverseRelationships()
). So you could actually set that property to true and get rid of the
setXxxxRelationship method (or at least add @Deprecated to it so it can be
hidden from code-assist) from your eogen template. Mike Schrag wrote that
feature …. and it does the "right" thing. However, IIRC it is 'false' by
default.
On a related note, with regards tens of millions on one side of a to-many ….
that will kill your performance on saving a change to that relationship unless
you make the relationship a one-sided relationship. @see
er.extensions.eof.ERXUnmodeledToManyRelationship<S, D> for one solution to that
situation. I recommend using an "unmodeled" toMany for any relationship where
the toMany can be in the thousands. YMMV.
In any case, here is an example of what my own eogen template spits out……
public wk.cheetah.eof.CTReseller reseller() {
return (wk.cheetah.eof.CTReseller)storedValueForKey("reseller");
}
public void setReseller(wk.cheetah.eof.CTReseller value) {
takeStoredValueForKey(value, "reseller");
}
public void setResellerRelationship(wk.cheetah.eof.CTReseller value) {
if (_CTUser.LOG.isDebugEnabled()) {
_CTUser.LOG.debug("updating reseller from " + reseller() + " to " +
value);
}
if
(er.extensions.eof.ERXGenericRecord.InverseRelationshipUpdater.updateInverseRelationships())
{
setReseller(value);
}
else if (value == null) {
wk.cheetah.eof.CTReseller oldValue = reseller();
if (oldValue != null) {
removeObjectFromBothSidesOfRelationshipWithKey(oldValue,
"reseller");
}
} else {
addObjectToBothSidesOfRelationshipWithKey(value, "reseller");
}
}
Regards, Kieran
On Aug 2, 2011, at 11:53 AM, George Domurot wrote:
> Hi Marius,
>
> This is a great question. setUserRelationship is a Wonder / EOGenerator
> template addition.
>
> setUserRelationship will do the job of adding your object to both side of the
> relationship. However, let's say the inverse relationship is pointing to
> tens of millions of other objects. If you revealed this array, you could use
> setUser to avoid the penalty of managing the flip-side of the relationship.
> However, in that case, you probably shouldn't reveal such an array as an
> attribute.
>
> -G
>
> On Aug 2, 2011, at 1:21 AM, Marius Soutier wrote:
>
>> Hi,
>>
>> one thing that's always confused me and which causes a bug every now and
>> then is for a given relationship, let's call it user, two setters are
>> generated:
>> * `setUser(User user)`
>> * `setUserRelationship(User user)`
>> while only one getter `user()` is generated.
>>
>> When calling `setUser()`, the field in the database is populated, but EOF
>> doesn't understand the relationship was set which causes all kinds of weird
>> bugs. So what's the point of the `setUser()` method?
>>
>> Thanks,
>> - Marius
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/george%40boxofficetickets.com
>>
>> This email sent to geo...@boxofficetickets.com
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/kelleherk%40gmail.com
>
> This email sent to kelleh...@gmail.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
