On Fri, 2004-01-23 at 17:08, Richard van Paasen wrote:
Consider this just a incentive to keep the database related code separated from the freevo code so that e.g. mysql or postgresql can replace sqlite. I've seen projects that incorporate sql statements directly into the program code...
Having gone through in my professional service the transition from one database to another I would advise against this. I was going to bring this up with dischi, but will state my piece here.
I would suggest the plugin stategy, we have used successfully elsewhere. Failing that I would rather see a rpcxml (or some other web service API) or at the very least the judicious use of the Business Delegate design pattern to keep the SQL as far away as possible from real code and just use abstract methods and objects from our software rather than some class from the database interaction layer.
I agree with this as well, keep DB code and Freevo code seperate. The use of plugins could play a great role here. It might be a great idea to start by creating a dbplugin object for any potential database plugins to extend, therefore we can define an interface there. I can imagine several possible types of db plugins:
1) simple, local sqlite - fast.
2) client / server sqlite. we could wrap plugin #1 up in a helper and xmlrpc server, this plugin shovels requests off to it. this would reuse the code in plugin 1.
3) plugin for database X (mysql, etc), this too extends the dbplugin object / interface. Your milage may vary. :)
This we can define the interface and not have to conform to some individual piece of SQL softwares view of what the standard is. And
Bingo.
believe me they widely vary. And can use the best thing available. Also
They sure do.
-Rob
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
