Re: EOModeling
Re: EOModeling
- Subject: Re: EOModeling
- From: Chuck Hill <email@hidden>
- Date: Mon, 12 Jan 2004 12:42:56 -0800
- Organization: Global Village Consulting, Inc.
That depends entirely on the implementation. There is such an EC in
our forthcoming book. It avoids this and many other problems such as
with nested editing context. Keeping it at the EC level allows for a
great deal more flexibility and permits deferred calculations,
notifications, etc. which I think would be difficult to do at the
adapter operation level.
Chuck
Pierre Frisch wrote:
There is a problem with doing that at the EC level. You flag more
modifications than required. If you have a many-to-many relation and you
add a new relation between two objects both objects will be marked as
modified as well as the intermediary entity (which is inserted). If you
change the modifiedOn based on the list of object in the EC then you
will do a real modification to the two entities that will force two more
write to the database i.e. instead of doing an insert in the joint table
you will do an insert and two updates.
I have found another way of doing it. Add a delegate to the
DatabaseContext and implements the
databaseContextWillPerformAdaptorOperations() in the method iterate
through the operations and add your mofidiedOn values to the changed
values for all operations except the deletes. This works around the
previous problem as the EC is smart enough to only generate the
operations that are necessary.
Pierre
--
Pierre Frisch
sPearWay Ltd.
sPearCat Web Catalogs, the flexibility of custom design, the price of a
package.
http://www.spearcat.com/
On Jan 12, 2004, at 11:54, Chuck Hill wrote:
What this won't do is to set the last update date when the object is
later modified. You may be tempted to do thing in validateForSave.
Don't. It will eventually bring you grief.
The best way I know of to handle this is to create an ec sub-class
that involved the eo in state changes (willUpdate, willDelete,
didDelete, didUpdate etc.). I'm pretty sure there is one on Project
WONDER. There might also be examples on wocode or wodev.
Chuck
Drew Thoeni wrote:
Like Karl, I leave them in each class (or table at the database level).
If you are using OpenBase, it defaults a timestamp (_timestamp)
automatically.
Here's the code Karl spoke of. It took me a bit to figure this out
when I first ran into it. The code goes into the class.java file
(where class is the class name). "setLastUpdate" is an example set
method in this class. Your's will be whatever you call it. In this
example, the timestamp gets set when a new object is created using
the class definition. If you then allow the user to edit the object
on a web page, time passes. So the timestamp can be off by the
difference in how long it takes the user to edit and then save the
object.
public void awakeFromInsertion(EOEditingContext ec) {
super.awakeFromInsertion(ec);
setLastUpdate(new NSTimestamp());
}
Drew
On Jan 10, 2004, at 11:56 AM, james cicenia wrote:
First I want to thank everyone who has replied to my "newbie" thread.
I have now refactored my design to break up my "Project" table to
actually
be three ala Chuck's advice.
My new question is... I like to have audit fields in my databases
so that
every row is stamped with a creation date/user and last mod date/user.
Should I start a separate base object that includes these "audit"
attributes
and then create a corresponding "audit" table in the database? Or,
should
I just leave them as attributes in my classes and just store the
attributes as
columns in the database?
thanks again.
-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.
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
Progress is the mother of all problems.
- G. K. Chesterton
_______________________________________________
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.
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
Progress is the mother of all problems.
- G. K. Chesterton
_______________________________________________
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.