> 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.
From: Toby Johnson <public@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.