PDO OR Database abstraction
Brought to you by:
canajun2eh,
yalnifj
Menu
▾
▴
OK, Now I have had some time to review the current changes to the code base, I'm seeing the same problems being duplicated when they could simply be eliminated. In theory it should be possible to replace the class_pgv_db with the existing ADOdb class without too much difficulty, but the problem is with some of the SQL and with the vast array of escapeSimple calls which I'd already eliminated by simply passing the variables as parameters and letting the abstraction layer deal with it.
What is the plan for class_pgv_db ? Will it be improved to add some of the missing SQL abstraction, or will that still have to be handled in the rest of the code ( FIRST SKIP processing, SUBSTRING and the like )
I presume that the current comment structure will be updated to PHPDoc format soon? PGV was nice in that I could run it into the bitweaver doc tree without any changes - unlike some other packages!
I need to decide if I simply scrap what I have already done to create a cross database port, with smarty templated output or carry on with the earlier port and see if I can pull some of the improvements in as time goes by. I have a number of areas that cut directly across PGV anyway. Media handling is done via the gallery system within bitweaver and images/files are simply accessed from that, and the map stuff is replaced with gmap and mapper packages. I'm simply looking to handle the GEDCOM data and leave many of the extensions to other existing packages. All of the user management and security is handled by bitweaver so none of those tables are created.
( The PHP5 mangling of things is not helping - despite the fact that I've never used PHP4 all of the bw code base still supports it, so I've not had to worry about the PHP5 extensions to classes :) )
<<In theory it should be possible to replace the class_pgv_db with the existing ADOdb class>>
We decided to replace Pear::DB with PDO for a number of reasons. The discussions are in the forum archives.
ADOdb was considered. However, we don't need a fully-blown abstration layer, just an interface layer.
I confess I didn't perform any performance tests myself, but all the ones I read said that ADOdb was much slower than PDO.
<<What is the plan for class_pgv_db>>
It is just a simple wrapper for PDO that provides logging and some "syntactic sugar" to reduce the verbosity. I wrote some documentation for it here:
http://wiki.phpgedview.net/en/index.php?title=PGV_Database_Functions
My current plans for database handling in PGV are:
1) replace Pear::DB with PDO. I'm 50% done on this.
2) provide a sqlite2 -> sqlite3 migration path. I've written a basic version of this.
3) provide a means for updating the database schema without re-importing the gedcoms. I've already written this (for another application), but it needs a few tweaks to work with PGV's modules.
<< I confess I didn't perform any performance tests myself, but all the ones I read said that ADOdb was much slower than PDO. >>
It depends on both what you are doing and how ADOdb is installed. The raw library is as slow as PEARxxx but once you install the extension a lot of the core stuff is fast. THAT is what should have been simply imported into PHP rather than creating a lot of new code.
The problem with PDO is that it's a half way house and does not address the real problems. People write for PDO the same as they do for a native driver which means non transportable SQL! Which is one of the problems I'm hitting again with PGV. and even the data abstraction in PDO is not always transparent.
<<3) provide a means for updating the database schema without re-importing the gedcoms. I've already written this (for another application), but it needs a few tweaks to work with PGV's modules. >>
We have a transparent update structure on bitweaver and I have updated the phpgedview package so that it handles the new schema. I have an upgrade script to port the existing tables but reloading the gedcom is a good test anyway. In addition to handling upgrade scripts it can port a complete database from one engine to another. And is being used across several engines currently. I'm not quite sure which version of PGV the current port is based on, and it does the job, so it may be that I simply ignore the new stuff in PGV.
But it would be nice if the database specific SQL was relegated to the PDO module, then at least there is only one place to fix things between database platforms. THAT is what ADOdb provides, and covers a lot of the little things that currently are being ignored by PDO :( The bitweaver core has been written so that you can actually change the abstraction library, and PEAR:DB is available as an alternative, but no one has written a PDO one, since you simply use PDO via ADOdb - which *IS* slower than using the native library in ADOdb ..... THAT is something I would be willing to spend some time on within the PGV code base!