Re: EOModeler Conceptual Question
Re: EOModeler Conceptual Question
- Subject: Re: EOModeler Conceptual Question
- From: Jonathan Rochkind <email@hidden>
- Date: Tue, 13 Jan 2004 16:13:51 -0600
At 3:10 PM -0600 1/13/04, james cicenia wrote:
Hello -
If my portal screen instantiates a few sets of object arrays for session1 will
those objects be only quickly referenced by user2 is session2? Or will it
have to go out and retrieve those objects again? Is Web Objects smart
enough to know that they are the same set of objects and share them?
Yes and no. Every EO object (by which I mean an object that
implements EOEnterpriseObject interface; generally, an object in EOF
that represents a database row. EOF is the framework WebObjects uses
for db access)... um, where were we. Every EO object has an
underlying 'snapshot' of it's values kept by lower level EOF objects.
Unless you've done some customization in your app to create multiple
EOF stacks, there is only one of these snapshots that exists. It is
used by all EOEditingContexts. EOEditingContext is the other
relevant object here---normally, an EOEditingContext is only used by
one session, not shared between sessions. And in the most basic
setup, each session only has one EOEditingContext (held in
session().defaultEditingContext() ). But the important thing is an
EOEditingContext.
The actual EO objects are _not_ shared between EOEditingContects
(ECs), no. Each EC has it's own EO object. If two ECs both have an
EO representing the same row in the db, then it's still two different
EO objects. (Sharing one snapshot at the lower levels).
Chuck Hill recently posted that the actual member data of the EO, the
Strings or Integers or whatever (immutable!) data makes up it's
attributes, actually are shared between EOs. This makes sense, since
the data objects themselves are immutable. Once you've set an
attribute of the EO to some new value (new immutable data object), it
of course won't be in common with attributes of an EO representing
the same db row in another EC. If you follow.
Apple's book on EOF, on the webobjects documentation page, is
actually quite good, and well worth reading. It explains much of this
stuff.
Finally, I am planning on using my lastModDate and lastModUserId as
the optimistic lock fields. This would mean that I would want most
setMethods to also set the lastModeDate and lastModUserId. Would
this make it easier for edits to the database
I don't understand. What dificulties in "edits to the database" have
you had, or do you anticipate, and in what way do you think this
design would help with these dificulties?
and would it make it easier
for webobjects to know about changes to the "shared" objects?
Again, I'm not sure what you are asking about. What do you mean by
<< 'shared' objects >>? if you are talking about an
EOSharedEditingContext, there are some special considerations
involved, especially with changes to EOs in a shared EC. But I don't
think storing this sort of information is relevant. In general, if
you would like to store that data for your own purposes, that's fine.
It may indeed be useful for optimistic locking purposes. Beyond
that, I don't think these attributes will have any special meaning or
use to EOF.
--Jonathan
I look forward to any discussion.
James
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.