A) Clearly document the issue from the outset of the product.
Without an active third party community that enlightened these
issues, I feel sure I would have never been aware of them, and
probably would have switched development platforms in frustration
by now.
Cough. Cough.
http://developer.apple.com/documentation/WebObjects/
Enterprise_Objects/EnterpriseObjects/chapter_3_section_13.html#//
apple_ref/doc/uid/TP30001011-DontLinkChapterID_8-TPXREF146
And I quote, "Note that immediately after the enterprise object is
created, it is inserted into an editing context. As a cardinal rule,
all enterprise objects reside in an editing context. This is
necessary in order for enterprise objects to send and receive the
notifications necessary for change tracking and other mechanisms
within Enterprise Objects. So, for every enterprise object you
create, you must immediately insert it into an editing context."
http://developer.apple.com/documentation/WebObjects/
Enterprise_Objects/BusinessLogic/chapter_4_section_3.html#//apple_ref/
doc/uid/TP30001011-DontLinkChapterID_3-TPXREF140
"You may wonder why it’s not recommended to initialize an enterprise
object’s values in an object’s constructor. An enterprise object’s
constructor represents the earliest state in the life of a particular
object. The state of an enterprise object at the point of
construction is not complete; the object is not fully initialized. It
may not yet have been inserted into an editing context and it might
not even have been assigned a global ID. You don’t ever want to
manipulate an enterprise object that isn’t in an editing context or
that doesn’t have a global ID."
