being half asian, I have no problems reading it :-D Thanks for the reply
On 5/16/07, Dave Shuck <[EMAIL PROTECTED]> wrote:
Wow... I am typing/sending faster than I can proofread today. If you have trouble reading through the engrish, let me know. :) ~Dave On 5/16/07, Dave Shuck <[EMAIL PROTECTED]> wrote: > > Derek, I would have to test that but I think you may be right. > > This is probably a better approach: By taking the same approach my > first sugesstion, create an update() method in that object's stub CFC. > Pull out the query generated update method of reactor/projects/[your > project]/Dao/YourObjectDao.cfc, remove the offending field from the query > and place the editted query in your custom update() method in that stub > CFC. That way you aren't jacking with generated project files. > > ~Dave > > On 5/16/07, derek bumpas < [EMAIL PROTECTED]> wrote: > > > > 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/ > > > > > > > -- > ~Dave Shuck > [EMAIL PROTECTED] > http://daveshuck.instantspot.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/
