Mark - First off, thanks for the feedback on the caching item. I suspect you're right. There's nothing stopping someone from implementing their own caching mechanism to store records and/or query results. Is it really an ORM framework's job to cache data? I'm not sure.
Furthermore, all of your suggestions are great. I strongly encourage you to add these to trac as enhancement request for reactor 2.0. Here's some feedback right now: - Ability to have two datasources: This is planned for reactor 2, but not exactly as you intended. I've been thinking more about being able to read and write data from two different data sources, but not to the point where reads and writes could come from different datasources for one configured object. - More control over cascading validation: Eh? Yea, I can see where you don't wanted to validate a user, when you add a news item, but what's a user got to do with that news item? Furthermore, I thought Reactor only validated when the object was dirty. Hmmm..... But yea, I can see a validate(cascade=false) just like with save. - Formal definition of compound objects: I think you mean where a FooUser might be a result of a combination of fields from the Foo and User tables. I would love for you to open a ticket on this and give a lot of details as to how you would like this to work. - Object cache/sized pool: planned for reactor 2. - Use of conventions to auto-configure reator: This is not going to happen. It was the initial intent of Reactor and after many, many, forhead bruises I decided that configuration was a more elegant solution. Doug -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Stanton Sent: Monday, October 09, 2006 8:59 PM To: [email protected] Subject: Re: [Reactor for CF] Big speed update in latest commit Hey All My 2 cents... +1 to everything that makes reactor generate and execute queries faster. -1 to everything that involves reactor caching the results of queries. Why? I really think that the effort spent on building a custom data caching system is going to be better spent elsewhere. Most DB's have an in-built caching system - many, many hours have gone into designing and optimising these caches. I don't think Reactor is likely to be able to provide a generic caching system that improves on what is already out there. Personally I don't even like CF's query caching mechanisms as they only partially solve the problem and don't allow sufficient control. If I need have to cache data at the CF level I much prefer the approach of caching the generated (HTML) output. If an application has a specific caching requirement - then it should be built based on the specific domain requirments. If the application just needs a generic cache mechanism to speed it up a bit - the DB can do this well enough. My wishlist for Reactor: + Ability to have two datasources (one for SELECTs and one for everything else), with the ability to use the 2nd one for specific SELECTs that need real time results. We are going to be running in a clustered configuration with a master & slave DB server - we are currently looking at having two whole instances of reactor in our Coldspring config to manage this. + More control over cascading validation (No I don't want to validate the user right now - I'm creating an news item!) + Improved debugging. When I get an error down in abstractRecord or objectTranslator - there must be a better way of working out what is going wrong than hacking cfdumps into the core framework files. + Formal definition of compound objects. + Object cache/sized pool (for stateful objects that get created and destroyed a lot like record, TO, validator and iterator). + Use of conventions to auto-configure reator. The main source of DB structure information should be the DB structure itself. The xml file should be a mechanism for overriding what reactor has already guessed, or providing additional information. ActiveRecord is a good example of how this can be done. Cheers Mark PS - Duckies & the new speed update both seem to be working well for me. -- Mark Stanton Gruden Pty Ltd http://www.gruden.com -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
