I disagree with this sentiment. It's often not the best idea, but if there are practical reasons as to why it's a good idea, then the DB is appropriate. This is particuarily important when you consider configuration settings that can be made from an application. It might no't make sense to store that in XML/INI in many cases.
Doug Hughes, President Alagad Inc. [email protected] 888 Alagad4 (x300) Office: 919-550-0755 Fax: 888-248-7836 On Wed, Apr 22, 2009 at 1:34 PM, Al <[email protected]> wrote: > > Configuration settings in a database is a no-go. It's gotta be a > simple text file, either XML or in INI format. > > On Apr 22, 11:40 am, Fernando Lopez <[email protected]> wrote: > > Interesting question > > we are working on a project where we found the same issue. > > > > We use ANT to deploy things to Dev Test and Prod, we are brand new to the > > whole process so we didn't want to get too fancy with ANT. > > We didn't want to change CS or any XML file for Dev/Test or prod either. > The > > deploy script we have is not very smart, check things out from CVS and > then > > move them to Dev/test or prod. It doesn't even reload the app if we > change > > something on CS, again I said we are new to ANT. > > > > So we ended up with a nice solution, created a CONFIG table in the > > application. > > > > The table has two columns Config_name and Config_value > > Some of the values we have there for config_name are > > > > applicationPath > > BizServicesEmail > > ConsumerAffairsEmail > > FailedRecipient > > systemErrorRecipient > > xmlErrorRecipient > > > > then we created a small service that only gets us the values from the > table > > and we can use the values on the application without changing the code or > > changing config files in the different environments > > > > a call to get the recipients for an email would look like this > > > > <cfset emailRecipients > > =variables.appConfigService.getappConfigValue("FailedRecipient") /> > > > > From there you can use the value on your code as you please. > > > > Just this morning I got a ticket asking to add a new person to the > > notification list when a transaction fails. > > > > Just went to the database and updated the record for "FailedRecipient", > > didn't have to change XML files, didn't have to deploy anything back to > > prod, didn't have to worry about initializing the application again, it > just > > worked. > > > > I'm not saying this is the final answer to your problems but just another > > idea that we found very simple and easy to implement and support. > > > > Fernando > > > > > > > > On Wed, Apr 22, 2009 at 10:10 AM, Doug Hughes <[email protected]> > wrote: > > > Al - > > > > > I think you're headed in the right direction. Essentially, what you're > > > saying is that your configuration settings need to change in your > ColdSpring > > > XML as you deploy from development to staging and production. > > > > > The way we tend to handle that at Alagad is to keep the development > version > > > of ColdSpring.xml in our SVN repo. So, the developers would always use > the > > > development version of the ColdSpring config. (There are gradiations > on > > > this, but they're not really relevant to your question.) > > > > > We then automate the deployment process to staging and production using > > > Ant. As a part of the deployment process we modify the ColdSpring > > > configuration to use our production settings. > > > > > So, for example, if we had a component for sending email we might have > two > > > objects configured in coldspring, an EmailSender and a MockEmailSender. > In > > > development anything that needed to send email would use the > EmailSender. > > > When we deploy to staging or production we might replace instances of > the > > > MockEmailSender with EmailSender. Actually, in all honesty, I simply > don't > > > configure the mail server in development and look in the undeliverable > mail > > > folder to make sure messages are getting created correctly. However, > there > > > are other instances where settings need to change between development > and > > > staging or production and we use Ant to make those settings. > > > > > In particular, we tend to use CFAnt as a part of our Ant deployment > process > > > so we can make settings changes to the ColdFusion server as well. For > > > example, we can configure datasources, turn on trusted caching, clear > the > > > template cache, configure event gateways, start them, etc, all from one > > > script. And, because it's Ant, running it from Eclipse is really, > really, > > > easy. > > > > > I hope that helps! > > > > > Doug Hughes, President > > > Alagad Inc. > > > [email protected] > > > 888 Alagad4 (x300) > > > Office: 919-550-0755 > > > Fax: 888-248-7836 > > > > > On Wed, Apr 22, 2009 at 9:46 AM, Al <[email protected]> wrote: > > > > >> I'm wondering how people manage differing configuration settings for > > >> the same app in different environments. > > > > >> Let me expand on what I mean. > > > > >> We have three tiers of servers: DEVELOPMENT, TEST, and PRODUCTION > > >> (hereafter D, T, P). For each of our applications we will have > > >> settings that vary based on environment. For instance, we may have a > > >> "test e-mail" to trap any outgoing e-mail and re-route it to the > > >> address in the setting rather than letting it go to the actual > > >> recipient. (Helps prevent messages being sent to live people from an > > >> app being tested.) In D that would probably be set to the development > > >> team, in T it would be set to the test team, and in P it would be > > >> NULL. Every app has a couple or half-dozen such settings. > > > > >> In the past, MG1.1, I'd create three separate ModelGlue.xml files and > > >> they'd each have differences in their CONFIG blocks, but everything > > >> else would be the same. (They would be renamed to ModelGlue.xml on > > >> each server during deployment.) That worked okay, but it meant that > > >> whenever an event-handler or message-listener got changed, I'd have to > > >> change three files. Not the end of the world, but we did have cases > > >> where people with less attention to detail forgot to change the > > >> production version, for instance. > > > > >> I then started using GetModelGlue().GetConfigBean() and having only > > >> one version of ModelGlue.xml and a config.xml for each of my three > > >> environments. A little more work, but I only had to change all three > > >> if I was adding a configuration setting; the application plumbing was > > >> just the one file. That works much better. > > > > >> However, I'm now forging ahead with developing using MG2. > > >> Configuration settings are in Coldspring.xml. That's fine, but I'm > > >> also looking to leverage Coldspring's power to define my components. > > >> Obviously, they'll be the same no matter what environment the > > >> application is in, but the config blocks will have to differ. This > > >> puts me back to the same basic problem I had with the versions of > > >> ModelGlue.xml for each environment. > > > > >> So, before I go too far down the rabbit hole, what do other people do > > >> to manage multiple configurations of a single application?- Hide > quoted text - > > > > - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "model-glue" 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/model-glue?hl=en For more about Model-Glue, check http://www.model-glue.com . -~----------~----~----~----~------~----~------~--~---
