Hi Mark,
Before setting primary keys as class properties I would really
question my design. This question typically occurs when you use the
primary to convey meaning about the object and this can usually
better be expressed in the object itself. This will give you a better
object design and a more readable code. In 10 years developing with
WebObjects I am yet to see a problem that could not be worked around
that way. Primary key should left at the database layer. The
application layer should manipulate EOGlobalID you will save you self
and the developer that will fix your code after you a lot of trouble
and time by keeping that encapsulation.
You are right EOF make the assumption that primary keys are not class
property. I do not think anything break in the current version if you
make them class properties and consider them as read only but that is
not guaranteed for the future. Primary Keys are considered private to
the EOControl layer and should only be accessed directly if you are
writing extension to that layer.
As for optimizing there are lots of way of doing it within EOF and
for the same reason you should probably try those very hard before
writing custom SQL code. The same apply here I have used all sort of
delegate and even written custom qualifiers but I have always stuck
to the rule that I do not embed SQL code in the application layer. If
you are missing feature to optimize your application please file a
bug report. I promise that it will be read.
Thanks
Pierre
--
Pierre Frisch
[EMAIL PROTECTED]
On 3-Feb-07, at 3:36 PM, Steven Mark McCraw wrote:
Hi everyone,
I recall reading in some of the early Apple WebObjects
documentation that it's a huge terrible thing to mark your foreign
and primary keys as class properties (e.g. check the little diamond
in EOModeler so that your generated classes give you setters and
getters to access them directly). Over the years, I've often
thought it would be convenient to have the keys as class
properties, particularly when I've had to write custom queries. I
know EOUtilities gives you methods to get the primary and foreign
keys for an object, but using these are kind of a pain compared to
just calling a simple accessor method.
I've actually set keys as class properties a few times, but
whenever a strange EOF exception cropped up, this was the first
thing I always changed back (in a rather superstitious, paranoid
way) for fear that somehow having the keys as class properties was
giving EOF a fit. I started thinking about it again the other day
for some reason, and frankly I can't think of any reason it should
have an effect on EOF, so I thought I would pose the question to
the list.
Is having keys as class properties just something that is for some
reason considered "bad form" by the early documentation writers at
Apple (I recall the same documentation firmly asserting that you
never need to do anything outside EOF, but in the real world this
isn't always practical when you need to optimize)? Or is there in
fact something about having keys as class properties that throws a
monkey wrench into EOF at unpredictable times?
Thanks in advance for help/discussion.
Mark
_______________________________________________
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/pierre%
40apple.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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]
