Am 14.11.2012 um 17:57 schrieb Jesse Tayler <jtay...@oeinc.com>:
> you got some backtrace on that funky action?

Happens also when a method using that attribute is directly invoked by a wod 
binding, in a component using autolocking.


Am 14.11.2012 um 18:21 schrieb Chuck Hill <ch...@global-village.net>:
> Also the EOModel checks are only enforced when saveChanges() runs.  So it is 
> possible that a bug in your code is setting these to null before you try to 
> use them. 

Like I said, happens on *fetched* EOs, not on newly created ones. And as the 
database has a NOT NULL constraint on the column, I don't see how that 
attribute can end up being null in the fetched EO, except through a bug in EOF.


> On 2012-11-14, at 9:16 AM, Ramsey Gurley wrote:
>> I have seen that in apps that violate the commandments:
>> 
>> http://wiki.wocommunity.org/pages/viewpage.action?pageId=1050329

I have done my best to follow those, although it's a large application so I 
can't rule out anything. Going through them just now, however I spotted two 
awakeFromInsertion() that didn't call super, although not in the classes I 
experienced those nasty NPE in.


>> If relationships are going missing and you are using nested ECs you may want 
>> to try
>> 
>> ec.setRetainsRegisteredObjects(true)
>> 
>> There's a known bug where EOs can be GCed which can result in nulls coming 
>> from required relationships. Nobody has managed to fix it in wonder yet.

I know, I already have that set in every editingcontext, and it eliminated a 
whole bunch of exceptions I frequently got before.


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

Reply via email to