On Sep 9, 2008, at 7:09 AM, Florijan Stamenkovic wrote:
Chuck, Dave,
Thanks for the input...
On Sep 08, 2008, at 19:37, Chuck Hill wrote:
I am guessing that (if EOF indeed does not accept modifications of
RO attributes) the purpose of this is to preserve existing data,
and in situations in which data is created outside of EOF?
I think you can create new objects with these attributes assigned a
value. You just can't change it afterwards.
If I read you correctly, then non-saved EOs can have their read only
attributes set. Which brings me to the core of the problem: do I
skip read only attributes when doing automatic EO generation or not?
I do not want to mess with pks and fks, but I am already dealing
with class properties only, so presumably they will not be in.
My feeling is that you should be setting them on entites that you
create. These would probably be non-null and read only, so you might
not have much choice.
Note that I am at the moment defining the general behavior. It will
be possible to override it per attribute, but only in a more
restrictive way: if the default behavior prohibits it, the att won't
be generated, but if it allows it, an overriding setting can be
provided to prevent any values being set.
At the moment I do:
// some attributes need to be skipped
if(att.isReadOnly() || att.isFlattened()) continue;
Maybe that should change to:
if(att.isDerived() || att.isFlattened() || isPK(att)) continue; //
check for PKs just in case they are exposed
I think that would be better.
The situation that Dave describes would not be covered, but I guess
one would not go about generating random values for an externally
served, deployed db :)
One would hope not! :-P
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
