Jcart wrote:
There are actually more caveat's than I originally thought there would be when taking on the project of writing a DB abstraction layer Smile
MDB and Ado have shown me this...
Why reinvent the wheel? You said it youself, there are already excelletent db abstraction layers that has addresse many issues.
PEAR and AdoDB are huuuuuge...although I found a benchmark and it didn't appear to add much of ahit in performance compared to native function calls, the codebase is still massive for all that it does...
Tons of error checking, etc...
I don't need that stuff for my purposes...I'm in need a fine tuned abstraction layer, because I'm using it in yet a further abstraction. I'm not one to typically complain about performance, in this case, because the advantage of abstraction is worth the investment in more powerful hardware.
I have my reasons for re-inventing the wheel.
1) I needed a good reason to read up on RDBMS
2) Smaller foot print
3) I like using code I copyright as my own in my commercial projects - I do however use some LGPL projects, I still have plans on re-writting them.
4) Where is the harm in options? Yet another DB abstraction layer can't be bad...
When and if I release my version, I'll be sure to do my homework and release docs explaining differences, design decisions and comparison between mine and others, even the crappy ones - so people can make educated choices as to why they might use mine...
I don't know why, but I dislike PEAR...although again I have used it (or some of it)...I dislike it...
Mostly, its because when I put my name on anything I like things to be done exactly as I do it...not nessecarily implementation, but interface for sure, variable naming, file naming & structure, commenting, etc...
I'm just anal about things like that
Plus I've already written a fairly large library of code which I use in projects and I don't yet have an abstraction layer, so heres my chance
