Alright, I appreciate the advise. I will implement using clone(), and if performance seems to be high afterward, I'll try to measure the difference and post about it.
Thank you again! -Denver On Aug 5, 8:33 pm, Mark Mandel <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
