[geeklog-devel] Our application for GSoC 2011
jmucchiello at yahoo.com
Sat Mar 5 14:35:07 EST 2011
> Regarding the DB abstraction layer: Ignoring the question about which one
> to pick, the most obvious consequence is that we would have to maintain
> two layers then: the new one and the old one. Obviously, all those legacy
> plugins with no current maintainer should continue working. Are these DB
> abstractions layers even supporting this parallel mode? What if they're
> caching something that is then changed behind their back by some legacy
> code that uses the old API?
My idea doesn't work? You create a pdo.class.php that implements the exist DB
class. In the configuration, you add a drop down item: MySQL, PostgreSQL, MS
SQL, and PDO. As long as pdo.class.php implement the existing interface,
everything should continue working including older plugins. After that, you
declare Geeklog 1.9 core will drop independent use of mysql.classs.php,
pgsql.class.php and mssql.class.php. And core 1.9 would start using the PDO
library directly for new code. This gives Geeklog access to bind parameters
finally. Old plugins would continue working through the legacy library.
I suspect you are thinking about using something kind of ORM. Don't.
Retrofitting an ORM onto existing SQL is a pain.
More information about the geeklog-devel