> Kern> When the Bacula drivers become shared objects, Bacula will be > Kern> capable of working with multiple different database types > Kern> simultaneously so any new implementation should include that > Kern> possibility.
I wish you luck in supporting it -- you're going to need it. I think the problems of using multiple databases for Bacula internals and supporting multiple types of database clients are substantially different, and if you want to support multiple types of databases for the internals you'll either need to federate the disparate databases into one view, or pick one for Bacula's internal use and stick with it. I think there are serious integrity problems that you'll need to solve if you want to use federated databases for Bacula internals (eg, holographic table storage, and you'll need to deal with some really hard failure scenarios that Just Aren't Worth It). Reading a simple sequential file on daemon startup and storing the value in a global variable for use by the various database routines passes the KISS test in my book, but YMMV. Putting it a current config file is OK too. In either case, get the value at startup, stuff it somewhere and pass it behind the scenes. > So why is this a good thing? I've never understood the idea to have > different catalogs either, or what the design goal is. The original purpose of using the libdbi interface is to remove the details of the database implementation from the core Bacula code, which allows support of a much wider range of database engines without recoding for each one. Libdbi supports postgres, mysql, DB/2, Oracle, Sybase, kdb, etc, etc via vendor-supplied (and supported) plugins. As far as different catalogs go, I've never seen a point in it. Others may vary. > Should I be using different catalogs for each client? Not unless you have lots of free time to reconcile them in case of a disaster. > Should I be > using different Pools for each client? You can, but I wouldn't recommend it unless you have very odd retention or audit requirements for different clients AND lots of spare time to debug things. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
