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