Hmm, well, this may be a crazy idea, but here's what I'd do if I needed to accomplish what you are suggesting, which is to always return the same, synchronized datetime value regardless of which CF server the code was running on:
I'd create a DateHelper object with a getNow() method that would return a synchronized datetime. I would then inject that object into my decorators. I could then call getNow() on the DateHelper from within my decorator and I would know that, no matter which CF server I was on, I'd get the same synchonized datetime value. I'd implement my DateHelper by having it query the database and return getdate(), which would work for now. If you ever decided to change your implementation to use another technique to get a synchonized datetime, you would just have to change the internals of the DateHelper object, and none of the rest of your code would be affected. Again, this isn't necessarily something that I'd do, but off the top of my head it sounds like it might address your requirement. Cheers, Bob On Wed, May 27, 2009 at 10:09 PM, Cameron Childress <[email protected]> wrote: > > Actually, my workaround is just about exactly the same thing you are > doing. Unfortunately this uses the system datetime from CF, and not > the DB. With a cluster of 3 CF machines and one DB machine this could > result in 3 different times (if all the system times aren't > synchronized properly). > > I am trying to stay away from triggers here to make the code mor > eeasily deployable across different DB platforms, but do use the DB > time - something like the following: > > INSERT INTO user( > [...] > user_datecreated, > user_datemodified, > [...] > ) VALUES ( > [...] > now(), > now(), > [...]) > > I really don't want to start tinkering with the DB and adding triggers > right now so I think I may just move forward using decorators till I > get more comfortable with another alternate solution. > > -Cameron > > On Wed, May 27, 2009 at 8:06 PM, Bob Silverberg > <[email protected]> wrote: >> >> Hi Cameron, >> >> Welcome to the party! If you are currently maintaining those >> timestamps via the database (e.g., via triggers), you can continue to >> do that. You just need to make sure that you specify refresh-insert >> and refresh-update on the appropriate properties. For example: >> >> <property name="dateCreated" type="date" refresh-insert="true" /> >> <property name="dateModified" type="date" refresh-insert="true" >> refresh-update="true" /> >> >> If you are not maintaining that data via the database or you wish not >> to, you can use Transfer's event model to do it. I wrote a blog post >> quite awhile ago that describes how I do it >> (http://www.silverwareconsulting.com/index.cfm/2008/5/21/My-Take-on-Transfer-ORM-Event-Model-Examples--BeforeCreate-Example). >> >> Hopefully one of those ideas will work for you. >> >> Cheers, >> Bob >> >> On Wed, May 27, 2009 at 1:15 PM, Cameron Childress <[email protected]> >> wrote: >>> >>> I'm a little late to the party but just getting my feet wet with >>> Transfer. I'm trying it out on an existing project that I'm updating >>> and refactoring... >>> >>> Currently I use columns called dateModified and dateCreated in most >>> tables in this app and I use the DB for datetime stamps. I could just >>> set a default value on the column, but I don't think this will work >>> for me in both cases, since both are set on insert and only one of the >>> two is set on update. I could also use the client or CF server's >>> datetime, but I usually prefer using the DB's datestamp so I don't >>> have to worry about syncing time on all machines. >>> >>> Right now I am just using CF to set the datestamp, but was wondering >>> if anyone had any better ideas? >>> >>> -Cameron >>> >>> -- >>> Cameron Childress >>> Sumo Consulting Inc >>> http://www.sumoc.com >>> --- >>> cell: 678.637.5072 >>> aim: cameroncf >>> email: [email protected] >>> >>> > >>> >> >> >> >> -- >> Bob Silverberg >> www.silverwareconsulting.com >> >> > >> > > > > -- > Cameron Childress > Sumo Consulting Inc > http://www.sumoc.com > --- > cell: 678.637.5072 > aim: cameroncf > email: [email protected] > > > > -- Bob Silverberg www.silverwareconsulting.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 -~----------~----~----~----~------~----~------~--~---
