From: Craig B. <cr...@at...> - 2002-12-23 06:48:48
|
> I think you can have the best of both here. What I mean is that > you can use the ConfigDef to define the parameters and their > types, structure and relationships, *and* you can maintain those > rich structures in the database schema via the Backup::Config > 'API'. If you had methods for creating/reading/writing/deleting > configuration objects, and the ability to parse the ConfigDef and > create the SQL dynamically based on it's structure, then you have > a very flexible and powerful configuration tool. Imagine later > on you decide you don't need a parameter, so you just eliminate > it from the ConfigDef and poof! it's gone (cascaded) from the > database... Another time, you might add a new parameter comprised > of some random nested structure to ConfigDef, and poof! the tables, > sub-tables, primary/foreign-key relationships, etc are created > automatically in the database. With Craig's permission, we might > be able to use 'appb' as an example or maybe even a darn good Sure, if it's helpful, the code for synching the sql tables with the definitions from appb is fair game. Toby, if you can describe your ConfigDef in a bit more detail then Paul or I could see if some code from appb is useful. Craig |
From: Toby J. <pu...@to...> - 2002-12-23 13:44:44
|
> Sure, if it's helpful, the code for synching the sql tables with > the definitions from appb is fair game. > > Toby, if you can describe your ConfigDef in a bit more detail then > Paul or I could see if some code from appb is useful. > I'm not sure what you're wanting by "a bit more detail"? Did you see the email that started this thread in the other list? Also, the BackupPC::Config, BackupPC::Config::Db, and BackupPC::Config::Db::MySQL modules I checked in last week are all making use of it. |