On Fri, Aug 13, 2010 at 4:47 PM, Michael Pedersen <[email protected]>wrote:
> On Fri, Aug 13, 2010 at 5:27 PM, Kevin Horn <[email protected]> wrote: > >> I'm very skeptical of any idea which involves storing configuration >> information in a database (RDBMS). In my experience this causes more >> problems than it solves, especially as applications grow in size and >> complexity. The biggest problem with this approach (in my opinion, at >> least) is that once you start storing config info in a database, it becomes >> _very_ difficult to version-control. In my experience this ends up causing >> all kinds of nasty administrative problems down the road. Of course, that >> begs the question, what to do instead? >> > > Okay, now this issue is one I honestly had not considered. Asking such > questions is a very good thing in this case then. > > I'm opposed to the idea of writing a text file, myself, because of the > issues with guaranteeing exclusive access to that file for the duration of > the write. This problem becomes even more important on Windows machines. > However, what I would be more amenable to is an import/export function, > along with a changelog table. This would provide an easy ability to copy > config anywhere, along with the accountability of seeing who changed what > value when. > > How about that? Would that make for a decent compromise? > This _could_ work, but any such import/export system needs to be _very_ clearly documented, and as easy to use as possible. And when I say that it needs to be clearly documented, I don't just mean how to use it (which is obviously needed), but also _when_ and _why_ to use it. And what to do if something goes wrong. Also, such an import/export system can become an albatross in and of itself. What happens when/if you need to change the schema for it? If you decide to stick with a DB, _please_ make whatever data schema is involved simple enough that it shouldn't need to be changed often (or at all), and then draw a very definite line in the sand, after which you absolutely refuse to change it. I do like the idea of the changelog. The important part for me, though, is having a history of the config, so that changes can be easily backed out to a working version at 4 in the morning when an upgrade goes wrong. I keep getting Drupal deja vu. Drupal is a pretty well-designed system (despite being written in PHP), but this exact issue (configuration in DB) has come back to bite them time and time again. They're still trying to get away from it. For myself, it's unlikely that I will ever willingly use any extension that depends on config info in a DB. A VCS repository, though...hmmm. You could definitely use a hg repo or something as a back end, though it wouldn't be as straightforward. We did something like this many moons ago with Docudo (which was never finished...mostly due to lack of interest, though SVN was probably not the best choice for the back end). > The only reason I would be against using setuptools (via entrypoints) is >> that it _will_ be going away...eventually. However, this will likely take >> quite a while, and the distribute package should provide a fallback in case >> of future problems with the "official" setuptools release. So I think using >> setuptools' entrypoints is probably fine for now, with the following >> caveats: >> > > Well, if it's going away, it's going away. I'll simply have to provide a > path to help extension developers migrate forward. > Yeah, that's basically what I was saying. > 1) there are a number of people who will not use any application that >> relies on setuptools, so be prepared to listen to some people gripe >> 2) be prepared for some pain when/if you ever need to change to whatever >> the replacement for entrypoints ends up being >> > > I think that both those points are more simply stated as "It doesn't matter > what you do. You are going to make a very vocal group of developers and > users upset. Get ready for it." > > Pretty much :) > I'd be willing to drop setuptools, but I do need something to provide > equivalent functionality. The entrypoints of setuptools is the only > popularly deployed/deployable item that I'm aware of. Options, before I > start coding, would be well received. > AFAIK, there is no other alternative for the time being. Which is why I use entrypoints when I need something like this. Just trying to make sure you head into this with eyes open. > -- > Michael J. Pedersen > My IM IDs: Jabber/[email protected], ICQ/103345809, > AIM/pedermj022171 > Yahoo/pedermj2002, MSN/[email protected] > -- You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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/turbogears-trunk?hl=en.
