Hi Dave, If I override the method setTimeStamp(), doesn't Reactor still try to insert a value (null or whatever) in the SQL? I understand that Reactor won't update data that hasn't changed, but it's the insert SQL that is giving me trouble.
Eric mentioned to override the sql code, but I'm trying to avoid that at this point. I may end up doing that if that's the only way. Thanks! Derek On 5/16/07, Dave Shuck <[EMAIL PROTECTED]> wrote:
All, First and foremost, to answer the original question from Derek, I would look at possibly putting in a setWhateverTemstamp() field method in the generated stub object cfc that basically overloads the default one that is created that basically does nothing at all and lets MySQL do the timestamping you are using. To Jeff/Eric, both Aaron Lynch and I have done extensive development with Reactor. I believe that it is amazingly powerful, yet it has some performance problems that are impossible to ignore. Unfortunately they are not limited to the areas that Eric described. I don't believe that it is dying, as evidenced by the email list the past week or so with some talented developers looking under the covers at some issues that might be part of the performance problem. That said, without a doubt Transfer is the new ORM project that is getting the most (well-deserved) attention at the moment. It does some really intelligent caching, has a far smaller performance footprint, is very flexible (for instance using decorators around object as I did in my presentation) by use of the decorator pattern, and offers the same custom abstracted querying that Reactor allows, but uses a *FAR* lighter approach with TQL (Transfer Query Language) as opposed to the Reactor OO Queries. We still have Reactor as the ORM for a few production applications such as InstantSpot, but we have had to manually cache the heck out of everything. There is very little "live" Reactor work going on when you hit the applications. The objects become way too expensive especially when they have children iterators upon children iterators. Feel free to hit me up off-list if you want further thoughts on it... or come to a CFUG meeting! We talk about this stuff all the time. :) ~Dave On 5/16/07, Jeff Lucido <[EMAIL PROTECTED]> wrote: > > Derek: > > I hate to say this ... but Reactor may be a dying a breed let alone it > folds under pressure. Take a look at Transfer (www.transfer-orm.com). It > is an ORM as well, but more efficient and supposedly better under load than > Reactor. We used Reactor for a project last year and had issues with load so > we scrapped it before we went to production. Transfer supposedly addresses > these issues and goes further. I have not used it yet, but saw an > interesting demo of it at cfObjective() two weeks ago. I think Dave Shuck > even did a preso using it at last weeks meeting. Dave S.: What is your > experience with Reactor vs. Transfer? > > -JSLucido > > ------------------------------ > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *derek bumpas > *Sent:* Wednesday, May 16, 2007 11:28 AM > *To:* [email protected] > *Subject:* [DFW CFUG] Reactor Question > > I've been spending a lot of time with Doug Hughes's reactor and am > loving it. > > I do have a quick question for you guys: > > Is there anyway to tell reactor to ignore a database column. I have a > MySQL timestamp field that is set to update on changes by MySQL. When using > the Reactor objects, Reactor by default sets these to null (I'm not setting > a value.) > > Any ideas? > > Thanks, > Derek > > > _______________________________________________ > Reply to DFWCFUG: > [email protected] > Subscribe/Unsubscribe: > http://lists1.safesecureweb.com/mailman/listinfo/list > List Archives: > http://www.mail-archive.com/list%40list.dfwcfug.org/ > http://www.mail-archive.com/list%40dfwcfug.org/ > DFWCFUG Sponsors: > www.instantspot.com/ > www.teksystems.com/ > > -- ~Dave Shuck [EMAIL PROTECTED] http://daveshuck.instantspot.com _______________________________________________ Reply to DFWCFUG: [email protected] Subscribe/Unsubscribe: http://lists1.safesecureweb.com/mailman/listinfo/list List Archives: http://www.mail-archive.com/list%40list.dfwcfug.org/ http://www.mail-archive.com/list%40dfwcfug.org/ DFWCFUG Sponsors: www.instantspot.com/ www.teksystems.com/
_______________________________________________ Reply to DFWCFUG: [email protected] Subscribe/Unsubscribe: http://lists1.safesecureweb.com/mailman/listinfo/list List Archives: http://www.mail-archive.com/list%40list.dfwcfug.org/ http://www.mail-archive.com/list%40dfwcfug.org/ DFWCFUG Sponsors: www.instantspot.com/ www.teksystems.com/
