Re: Opinions on static createŠ() methods for EOs

[Paul Hoadley]

On 22/02/2014, at 3:23 AM, Musall Maik  wrote:

> I’d leave it to the caller, too, but do an additional check if both EOs are 
> in the same editing context, and throw an exception if they aren’t. 

Thanks Maik.


-- 
Paul Hoadley
http://logicsquad.net/




 ___
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:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Opinions on static createŠ() methods for EOs

[Musall Maik]

Am 20.02.2014 um 08:15 schrieb Paul Hoadley :

> On 20/02/2014, at 4:55 PM, Dev WO  wrote:
> 
>> Someone will correct me if I'm wrong, but I think localInstanceIn is working 
>> only on an existing object in the datastore.
>> That means that if you create bar into ec2 and you try to do 
>> setBarRelationship(bar.localInstanceIn(ec1)) you will get a 
>> NullPointerException which could be difficult to track and debug if it 
>> happens in the eo class.
>> 
>> So I would recommend to not do it as a cross editingContext exception is 
>> "easier" to debug:)
> 
> Thanks Xavier, I had overlooked that.  That's going to be a complete 
> show-stopper (in the general case), isn't it Chuck?

I’d leave it to the caller, too, but do an additional check if both EOs are in 
the same editing context, and throw an exception if they aren’t. 

Maik ___
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:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Opinions on static createŠ() methods for EOs

[Chuck Hill]

Yes, I was not thinking of new objects either.  I guess that is another reason 
I prefer my way.  :-P

On 2/19/2014, 11:15 PM, "Paul Hoadley" wrote:

On 20/02/2014, at 4:55 PM, Dev WO 
mailto:webobje...@anazys.com>> wrote:

Someone will correct me if I'm wrong, but I think localInstanceIn is working 
only on an existing object in the datastore.
That means that if you create bar into ec2 and you try to do 
setBarRelationship(bar.localInstanceIn(ec1)) you will get a 
NullPointerException which could be difficult to track and debug if it happens 
in the eo class.

So I would recommend to not do it as a cross editingContext exception is 
"easier" to debug:)

Thanks Xavier, I had overlooked that.  That's going to be a complete 
show-stopper (in the general case), isn't it Chuck?


--
Paul Hoadley
http://logicsquad.net/

 ___
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:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Opinions on static createŠ() methods for EOs

[Paul Hoadley]

On 20/02/2014, at 4:55 PM, Dev WO  wrote:

> Someone will correct me if I'm wrong, but I think localInstanceIn is working 
> only on an existing object in the datastore.
> That means that if you create bar into ec2 and you try to do 
> setBarRelationship(bar.localInstanceIn(ec1)) you will get a 
> NullPointerException which could be difficult to track and debug if it 
> happens in the eo class.
> 
> So I would recommend to not do it as a cross editingContext exception is 
> "easier" to debug:)

Thanks Xavier, I had overlooked that.  That's going to be a complete 
show-stopper (in the general case), isn't it Chuck?


-- 
Paul Hoadley
http://logicsquad.net/

 ___
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:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Opinions on static createŠ() methods for EOs

[Dev WO]

Someone will correct me if I'm wrong, but I think localInstanceIn is working 
only on an existing object in the datastore.
That means that if you create bar into ec2 and you try to do 
setBarRelationship(bar.localInstanceIn(ec1)) you will get a 
NullPointerException which could be difficult to track and debug if it happens 
in the eo class.

So I would recommend to not do it as a cross editingContext exception is 
"easier" to debug:)

Xavier



> Hi Chuck,
> 
> On 20/02/2014, at 3:10 PM, Chuck Hill  wrote:
> 
>> It is always safe to call localInstance.  My personal preference is to force 
>> the caller to do that so that they are aware if they have cross EC 
>> references.
> 
> Ah OK.
> 
>> I can also see the argument for “just do what is safest”.
> 
> I hadn't thought of that benefit to leaving responsibility with the caller.  
> Anyway, I should pick one as I'm currently doing a bit of each with no 
> consistency.
> 
> 
> -- 
> Paul Hoadley
> http://logicsquad.net/
> 
> 
> 
> ___
> 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:
> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.com
> 
> This email sent to webobje...@anazys.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:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Opinions on static createŠ() methods for EOs

[Chuck Hill]

On 2/19/2014, 8:36 PM, "Paul Hoadley" wrote:

Hello,

Say I have an entity Foo.  Often I will override the static createFoo() method 
declared in _Foo.java, perhaps several times with different signatures for 
different uses.  Say Foo has a to-one relationship to Bar, and I supply bar as 
an argument.  I'm a bit inconsistent as to whether I call:

setBarRelationship(bar);

or:

setBarRelationship(bar.localInstanceIn(ec));

in the body of the method, where ec is obviously the EOEditingContext supplied 
as an argument.  I would have thought that doing the latter was more 
convenient, because then the caller never has to worry about whether or not she 
needs to or remembers to localInstance the related object herself.  But I note 
that the built-in templates _don't_ do this, so that _Foo.createFoo() would 
just call setBarRelationship(bar) if bar was an argument.

Are there any gotchas here?  Is it safe to always call localInstanceIn() in 
these static create methods, or should it be left up to the caller?


--
Paul Hoadley
http://logicsquad.net/




___
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:
https://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net

This email sent to ch...@global-village.net
 ___
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:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Opinions on static createŠ() methods for EOs

[Paul Hoadley]

Hi Chuck,

On 20/02/2014, at 3:10 PM, Chuck Hill  wrote:

> It is always safe to call localInstance.  My personal preference is to force 
> the caller to do that so that they are aware if they have cross EC references.

Ah OK.

> I can also see the argument for “just do what is safest”.

I hadn't thought of that benefit to leaving responsibility with the caller.  
Anyway, I should pick one as I'm currently doing a bit of each with no 
consistency.


-- 
Paul Hoadley
http://logicsquad.net/



 ___
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:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Opinions on static createŠ() methods for EOs

[Chuck Hill]

Hi Paul,

It is always safe to call localInstance.  My personal preference is to force 
the caller to do that so that they are aware if they have cross EC references.  
I can also see the argument for “just do what is safest”.

Chuck


On 2/19/2014, 8:36 PM, "Paul Hoadley" wrote:

Hello,

Say I have an entity Foo.  Often I will override the static createFoo() method 
declared in _Foo.java, perhaps several times with different signatures for 
different uses.  Say Foo has a to-one relationship to Bar, and I supply bar as 
an argument.  I'm a bit inconsistent as to whether I call:

setBarRelationship(bar);

or:

setBarRelationship(bar.localInstanceIn(ec));

in the body of the method, where ec is obviously the EOEditingContext supplied 
as an argument.  I would have thought that doing the latter was more 
convenient, because then the caller never has to worry about whether or not she 
needs to or remembers to localInstance the related object herself.  But I note 
that the built-in templates _don't_ do this, so that _Foo.createFoo() would 
just call setBarRelationship(bar) if bar was an argument.

Are there any gotchas here?  Is it safe to always call localInstanceIn() in 
these static create methods, or should it be left up to the caller?


--
Paul Hoadley
http://logicsquad.net/




___
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:
https://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net

This email sent to ch...@global-village.net
 ___
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:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com