At 04:42 PM 2/28/2002 -0500, Ajit Deshpande wrote: >On Thu, Feb 28, 2002 at 04:28:01PM -0500, Perrin Harkins wrote: .... >2. True database independence is quite utopian. So, if you are stuck > with a certain d/b, then might as well leverage all the rich set of > tools available.
Hi, It is my every intention to attain true database independence for the application code. Better yet, every piece of code that uses the P5EEx::Blue::Repository abstraction will be able to have their requests satisfied by any of the following (currently envisioned) Repository implementations. * P5EEx::Blue::Repository::DBI * P5EEx::Blue::Repository::File * P5EEx::Blue::Repository::BerkeleyDB * P5EEx::Blue::Repository::LDAP * P5EEx::Blue::Repository::HTML - for data stored in a web page * P5EEx::Blue::Repository::SOAP - remote data storage * P5EEx::Blue::Repository::Cache - use the Cache::Cache module I think you are correct to point out that every database has its advantages. I propose that the *configuration* of Repository::DBI at deployment-time (rather than the use of a distinct API at development- time) be used in order to maximize db-specific performance. For that matter, a company might choose to implement their own Repository driver (i.e. MyCompany::P5EE::Repository::Oracle) if they want to in order to take advantage of some nifty features. True database independence must be a primary goal of P5EE or the software which is developed for it will not be able to be widely deployed in the Enterprise! Stephen P.S. I am evaluating the degree to which the Repository interface is redundant to or complementary to such interfaces as Tangram, Alzabo, SPOPS, and Class::DBI. My hunch is that I will probably be able to implement the following drivers as well. * P5EEx::Blue::Repository::Tangram * P5EEx::Blue::Repository::Alzabo * P5EEx::Blue::Repository::SPOPS * P5EEx::Blue::Repository::ClassDBI We'll see.
