I know this isn't the sort of answer you're looking for, but in reality terms, it seems like you'd get a cleaner app long-term if instead of doing this work to manage running against multiple different schemas, you spent some time building an "automatic" schema update architecture. We have an app that has multiple cf servers hitting the same db, as well as multiple (dev only) dbs deployed, and that's what we did. It works well.
Basic idea is that the code has a version (a hard-coded number) and the db has a version (a one-row-one-column DBVersion table). The code checks if the two versions match. If the code is more recent than the db, it automatically runs the appropriate upgrade method (UpgradeTo2, UpgradeTo3, etc), each of which set the db version appropriately, until the versions match. If the db is more recent than the code, it either throws an exception, requiring the user to get more recent code onto that server, or if possible and worth building (I didn't) runs temporarily in some feature-limited mode to avoid the problem areas. So instead of directly modifying the db, you write the appropriate schema upgrade and promote it, along with the code that changes the code version, and any app code that needs to come with it. Once that code arrives at any server, the db gets upgraded. That in turn causes other servers to require more recent code. As you can imagine, the actual code to do this is pretty simple. Error handling and "locking" the db during upgrades are your biggest issues. Make sense? It's at least worth considering i think. On Wed, Jul 2, 2008 at 1:33 PM, Marc Esher <[EMAIL PROTECTED]> wrote: > > Thanks a lot, Alan. Maybe that's just what I need... baby steps and all. > > much appreciated. > > Marc > > On Wed, Jul 2, 2008 at 1:23 PM, Alan Livie <[EMAIL PROTECTED]> wrote: >> >> We're finally moving to Coldspring and the team are happy with working with >> our small custom factory. >> >> It was based on Rob Gonda's one, its easy for the team to learn from the >> source code and feels like a good stepping stone to Coldspring getting >> developers confident and up to speed. >> >> http://www.robgonda.com/blog/index.cfm/2007/2/23/Object-Factories-and-Circular-Dependencies >> >> We've had no trouble with it and its been used on our app for the last 12 >> months. >> >> Alan >> ________________________________________ >> From: [email protected] [EMAIL PROTECTED] On Behalf Of Marc Esher >> [EMAIL PROTECTED] >> Sent: 02 July 2008 18:18 >> To: [email protected] >> Subject: [CFCDEV] Re: Advice on >> >> @Sean, yup, makes perfect sense! >> >> @Alan, I think really what Sean's proposing is sort of just a variant >> on the abstract factory anyway. Or maybe I'm wrong about it, but when >> it gets into "objects that decide what objects to use", to me, that's >> a factory. be it one i roll myself or coldspring or lightwire, it's >> all just factories at that point (I think... maybe that's reducing it >> a bit much). >> >> I think where I am now is deciding how far to take it. One thing I >> have to consider, unfortunately, is maintenance a year from now. Where >> I currently work, the culture is currently decidedly "framework? huh? >> whoosie? whatda?" So if I were to convert this to using coldspring, >> that adds additional learning curve for the poor bastards who have to >> maintain it, because i sure as hell don't want to open this thing up >> again after I'm finished. if I roll my won, it'd just be in code in a >> simple factory object (or set of objects), and they'd at least be able >> to follow it right out of the box (I hope.). >> >> this does sound like a decision best put off until i've had a few beers >> though. >> >> and alan, thanks for the complement! >> >> marc >> >> On Wed, Jul 2, 2008 at 1:12 PM, Alan Livie <[EMAIL PROTECTED]> wrote: >>> >>> This is a good discussion! >>> >>> I must admit I like Brian's Abstract Factory idea but does it have to be as >>> complex as Abstract Factory (you can tell they scare me a bit :-) >>> >>> Would a simple Factory not do the job. ie the db can store in a table a >>> version number and the factory can give the Service the relevant DAO's / >>> Gateways it needs to work on the db? >>> >>> ie you have a standard xxxxxDAO.cfc and a xxxxxDAOv2-1.cfc and the Factory >>> determines what to use. >>> >>> You can do the same with your views if you need slightly different displays >>> and have a cfc handle the logic of what view to use. >>> >>> Even this factory approach has a strict Java / C# OO feel about it. It can >>> be even simpler so the factory just gets the version from the db and does a >>> <cfset >>> variables.xxxService.setxxxDAO(getBean("xxxDAOv#variables.qDbVersion.versionNumber#") >>> /> and the setter in the service has a type="any" ... ie no need for >>> interfaces or abstract dao class types >>> >>> Something along those lines anyway! >>> >>> Lovin' mxUnit by the way Marc :-) >>> >>> Alan >>> ________________________________________ >>> From: [email protected] [EMAIL PROTECTED] On Behalf Of Tom Chiverton >>> [EMAIL PROTECTED] >>> Sent: 02 July 2008 16:48 >>> To: [email protected] >>> Subject: [CFCDEV] Re: Advice on >>> >>> On Wednesday 02 Jul 2008, Marc Esher wrote: >>>> That's true. It's mainly a matter of time and money. If we have 10 >>>> systems, and there's a need to change (like my candy example), it >>>> generally is a need that arises from a single system but which will >>>> get pushed into all other systems eventually. It's just that it can >>>> take a bit of time to get the other systems in compliance. >>> >>> So would simply versioning the DB schema against a version of the >>> application >>> work then ? >>> Then as the other DBs get the same update done, you roll out the mathcing >>> application rev. ? >>> >>> -- >>> Tom Chiverton >>> >>> **************************************************** >>> >>> This email is sent for and on behalf of Halliwells LLP. >>> >>> Halliwells LLP is a limited liability partnership registered in England and >>> Wales under registered number OC307980 whose registered office address is >>> at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A >>> list of members is available for inspection at the registered office. Any >>> reference to a partner in relation to Halliwells LLP means a member of >>> Halliwells LLP. Regulated by The Solicitors Regulation Authority. >>> >>> CONFIDENTIALITY >>> >>> This email is intended only for the use of the addressee named above and >>> may be confidential or legally privileged. If you are not the addressee >>> you must not read it and must not use any information contained in nor copy >>> it nor inform any person other than Halliwells LLP or the addressee of its >>> existence or contents. If you have received this email in error please >>> delete it and notify Halliwells LLP IT Department on 0870 365 2500. >>> >>> For more information about Halliwells LLP visit www.halliwells.com. >>> >>> >>> >>> > >>> >> >> >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
