I have seen Reactor deployed in several ways now. What was suggested about pre-generating your Reactor objects has proved to be a solid experience.
There is some work involved though to make that easy. The table and column structure needs to be the same from one database to the other. The other alternative is have your staging server point to your production database. This is really up to you. If you want to verify all of your CRUD, you may not want to connect to production data. One way that I liked was to create a copy of the production database into another instance on the same machine. It was an empty database that was only meant for pre-deployment. So on prod.insertservername.com SQL Server, I had ProjectDB and ProjectDP. DP being for deployment. After my test script executed against ProjectDP, you can post the generated Reactor code in production mode and not have to worry about the first initial metadata read. _____ Along these lines of having a "development" and "production" db, especially once you have an application already in production that is undergoing further development, a few things you can do that can really help you keep your sanity (especially if using MS SQL Server): 1. Set up a DTS package that can take a "snapshot" of your production database - schema AND data, and "recreate" your development database with it. (Of course, you only do the snapshot after comparing schemas to make sure you haven't made schema changes in development that have not yet been "published" to live site, since making the snapshot would overwrite your pending db changes.) Generally you'd grab a clean snapshot after each major round of development was completed, and you were ready to start a new "session" or "task" of development. 2. Get yourself a license for Red Gate SQL Compare (http://www.red-gate.com <http://www.red-gate.com/> ). And if you don't want to do a DTS package, Red Gate offers a DATA sync app as well. The schema compare utility is the best $300 I ever invested in a tool - seriously. I can modify my database schema locally, and this tool keeps the live database schema in sync... and it's FAST and EASY. Works between my local SQL server and the live remote SQL server. Shows you what it's going to do first, and provides some excellent warnings. Can sync in either direction, if for some reason your live db schema changed directly, but not your dev copy. The obvious CYA recommendations apply... for more massive changes, you may still need to think about how to modify your in-production db, and you'll want to do pre-update backups of the live database before making ANY changes... but the Red Gate software has proven to be totally reliable and a godsend when it comes to application maintenance at the DB tier. No more "keeping track of what columns you changed, and how", or having to generate your own change scripts manually ALL the time. It works! Hope this helps, Marc -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
