Ha! Derek, let me know how that works, or if you happen to come up with a better approach.
~d On 5/16/07, derek bumpas <[EMAIL PROTECTED]> wrote:
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/
-- ~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/
