Re: DB, MDB2, PDO - Future of DB-Abstraction in PEAR

Andreas Korthaus wrote:

If I think about it again, the problem could be reduced to high offset values if you use unbuffered results. And those are rarely used in real world applications I think. Who wants to browse through thousends of result-sets with a large amount of data using a pager... even search-engines aren't used with really high offsets to make network-traffic a real problem?

And for most RDBMS that dont support LIMIT they do support CURSORS that let you skip around in the result set. Some also provide a way to atleast limit the rows in the result set using TOP or some variant of this. Or you rewrite the SQL. Either way you dont really need a fancy layer for this at all.

So you only need a solution in very special cases. So the only problem with using PDO directly are the two feature requests mentioned earlier. I think I should use a very simple wrapper class or child class, to make it easy to add functionality, if I run into issues I did not think about now. Such a class could be extended by another, db specific class, if I have special problems with a specific database.

Like I said you dont need to bother with sequences if you are willing to handle things inside the schema (which will need to be RDBMS dependent anyways). So this leaves just a single function for LIMIT support.

Perhaps I have to use 2 classes (DBWrite, DBRead), DBWrite wraps PDO methodes necessary to manipulate data, DBRead needs to wrap methodes to read data. So I can call DBWrite::exec() and DBRead::query() everywhere in my applications. Or I use one DB class which could detect if it's a manipulating query or not by parsing the first few characters from SQL. What about something like: if (preg_match('/^\s*U|I/i', $sql)) { $writing = TRUE; } else { $writing = FALSE; }

thats not going to work at all .. have a look at [M]DB[2]:isManip .. and not even that is 100% reliable. regards, Lukas