I think Matt's idea of ensuring that you clone() and then having an observer on beforeUpdate and beforeInsert to track what is currently in the cache vs what is in the object you are about to save, seems to sound like it would work.
I do worry about your application's performance however with all the extra load. Mark On Thu, Aug 6, 2009 at 11:26 AM, Denver <[email protected]> wrote: > > Haha, I think I haven't explained myself very well. > My application is intended to be used as a request tracking and > communications system between several different business units at my > corporation. The application has been built, and is functioning. The > business logic is spread out appropriately by function. > > Now that that is done, I want to add a layer to my application to > track *all* changes to *all* objects. Essentially, if the Accounting > department is working on a request sent from one of the Sales > departments, I want to record each time the Accounting department > changes the status of the request, each time they edit the categories > that are associated with the request, each time they reply to the > member(s) of the Sales department about this request, and each time > the Sales department provides more information to Accounting. > > At this point, I want to implement history-tracking in one place, and > it will be able to log all changes everywhere, and I shouldn't need to > change this history-logging mechanism very often at all, *certainly > not* every time I change an object, or its members! > > Does this make more sense? > > -Denver > > > On Aug 5, 3:12 pm, Matt Quackenbush <[email protected]> wrote: > > First of all, just for the sake of pointing out what may or may not > already > > be obvious, just because you use a decorator for one object certainly > does > > not require you to use decorators for all objects. > > > > Secondly, in my personal opinion, the business object (decorator in this > > case) is exactly where the business logic should be maintained. If your > > object does nothing but hold data, why bother with an object? Just go > with > > traditional structs, arrays, and queries. > > > > In order to avoid a corrupted cache, if you are requesting an object for > > editing purposes, you should always call clone() on it. I suppose that > you > > could check getIsDirty() prior to the save and, if true, grab another > object > > from Transfer to get your "old" values. > > > > I obviously do not know how you're modeling your application, but it > seems > > to me that if all of the logic for the entire application is held in "one > > place", the application would become very messy and difficult to maintain > in > > a hurry. > > > > HTH > > > -- E: [email protected] T: http://www.twitter.com/neurotic W: www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
