Re: New PDO-based DBAL/ORM for PEAR2

On Nov 20, 2007 5:10 PM, Alexey Borzov <borz_off@cs.msu.su> wrote: > Hi, > > > Lukas Kahwe Smith wrote: > >>> Please feel free to check out the code if you'd like to try it out or > >>> provide encouragement/suggestions/criticisms. The code is hosted on > >>> Google code, so bugs can be reported on the issues tracking system > >>> there (until it's ready to be voted on for inclusion in PEAR). Also, > >>> I'll be maintaining a wiki at that site that will contain details on > >>> how to use the package. I'd like to get a lot of people testing out > >>> the package and posting questions to the wiki so we can get a good > >>> idea what information the docs need to contain. Once we get a good > >>> set of wiki pages, it will be easy to port the content they contain > >>> to DocBook format. The package is very well documented and should be > >>> fairly easy to understand for anybody who's familiar with MDB2 and/or > >>> PDO. > >> > >> It looks good. I personally would remove the datatype and manager > >> stuff, as well as most of the things related to SQL abstraction since > >> this is a myth and adds bloat in the package (sequences and dates to > >> start with). I'd call Drivers -> Connections and remove the singleton > >> method. I wouldn't make a difference between one-to-one and > >> one-to-many relations. I don't > > > > Funny that I managed to port my CMS from MySQL to PostgreSQL in 2 hours > > (mostly fixing reliance on non deterministic group by's) and to SQLite > > in 3 hours (1 hour was used to add a feature to handle the fact the > > SQLite by default qualifies joined columns with the table name unless > > aliased) as it was based on MDB2. I should also mention that the > > installation tools based on MDB2_Schema needed no alterations. I also > > did not feel like I was artificially limiting myself. For example one > > thing that did require custom code was the internal search, which was > > based on MySQL's FULLTEXT indexes. But that was a minimal amount of work > > and a tiny addition to the code. Just to set the record straight. > > Porting something *from* MySQL isn't an impressive feat, due to its limitations. > Now if your abstraction layer allowed porting an application written and > optimised for Oracle (or PostgreSQL) *to* MySQL in 2 hours, that'll be something > to be proud of. > > Going for "database abstraction" is IMO an extremely bad thing, since it > encourages coding for the Lowest Common Denominator (MySQL / SQLite). Of course > having an unified API for fetching the rows helps a bit, but the underlying > logic should be written and optimised for each DBMS, not written for MySQL and > ported everywhere else as an afterthought. And that means hand-tuned separate > schemas, not a dumbed-down schema meta-language. Correct me if I am wrong, but you could still write your *whatever-specific* code and fire it up through query/exec and deal with it yourself. I mean, I like MDB2 not because my apps are constantly deployed with different backends (even though I have clients who use the same app but run MSSQL, Postgre, SQLite and MySQL) but the beauty lies within all the shortcuts. In general, and this is not meant to offend anyone (!), but all the opinions on DBALs should probably not be a part of this thread. Too many people already agreed that we want this in PEAR so let's discuss the use of DBALs (and if they suck, are bad and whatever) somewhere else. I look forward to seeing this package in PEAR2, I'd just vote for an easier name. :) Till