RE: [PEAR-DEV] DBM Compatibility layer

Yeah I doubt that an SQL parser is the way to go ... If you want to add another layer of abstraction I would rather suggest having the user not write SQL at all and rather build queries via a php object. Then you could do stuff like subselects and joins (or emulate the feature if it's missing). This would we be the easiest (although still very time consuming) to get true abstraction while still making use of all the advanced features that db's offer. That would do away with stuff like PEAR DB or Metabase (and of course the merger of the two that I am currently working on). That’s why I don't think that a query builder should be build in top of a "traditional" db abstraction layer but more as a replacement (or while its being developed in parallel). Best regards, Lukas Smith smith@dybnet.de _______________________________ DybNet Internet Solutions GbR Reuchlinstr. 10-11 Gebäude 4 1.OG Raum 6 (4.1.6) 10553 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de info@dybnet.de _______________________________ > -----Original Message----- > From: Brent Cook [mailto:busterb@mail.utexas.edu] > Sent: Friday, April 19, 2002 6:03 AM > To: Stig S. Bakken > Cc: Martin Jansen; pear-dev@lists.php.net > Subject: Re: [PEAR-DEV] DBM Compatibility layer > > > > On 18 Apr 2002, Stig S. Bakken wrote: > > > On Thu, 2002-04-18 at 20:08, Martin Jansen wrote: > > > On Thu, 18 Apr 2002 13:00:22 -0500 (CDT), Brent Cook wrote: > > > > > > > While I don't have it completely up to PEAR standards yet, I would > like > > > >your opinions on a DBM compatibility layer for PEAR. What I'm > proposing is > > > >something to go between the dbm functions in PEAR and an application > to > > > >smooth out inconsistencies between DBM implementations, sort of like > DB > > > >does for SQL databases but more like the anydbm module in Python > > > >��<���� > > > >4PΧ�%http://www.python.org/doc/current/lib/module-anydbm.html > > > > > > Do you think that it could API-wise fit in the structure of > > > PEAR::DB? IMO integrating the code into PEAR::DB would be much > > > nicer than making it an independent package. > > > > PEAR DB drivers may be independent packages, and this one should be if > > implemented as such. > > I looked at the DB_ldap code, and noticed that its API is a little > different than that of DB. For instance, with DB, you have query(). With > ldap, it's simpleQuery. The semantics of using these two are pretty > different, it appears. Of course, I understand that an LDAP server > implements a hierarchical database, while DB handles mostly relational > databases. > > It doesn't seem to me like the same interface necessarily fits all > database types, though perhaps this is not what you were suggesting. If > not, then were you just suggesting an appropriate location in PEAR? If so, > then could you define what essential to the DB API, that is, what makes > something fit the DB way of doing things? > > My intention at this early stage is to simply smooth access to dbm > databases using something similar to the API found here: > http://www.php.net/manual/en/ref.dbm.php > > Though they are referred to as databases, DBM is really very similar to a > flat filesystem, and related more to CSV files than a real queriable > system. So I propose that File is a better fit, at least for this > low-level. > > I have a vision for creating this kind of structure: > > DBM Object -> Table Object -> Database Object > > DBM would be for low-level data storage, Table for performs things like > selects, sorts, projects, min, max, etc. Database is for managing multiple > Tables, joins, interpreting schemas, etc. I have DBM and Table implemented > and in use, though DBM is the only one that I wouldn't be ashamed to show > anyone at this point! > > > Now that there's DB_ldap and more similar DB backends are starting to > > pop up, writing an generic SQL92 parser in lex/yacc/C is starting to > > make sense. > > Whoa! I was just kidding earlier about this ;) There's more to it just > parsing the SQL; you have to have an optimizer, an execution unit, > preferably a means to store multiple indexes, etc. It may be _tad_ > overkill. > > Plus, DBM, as it is, does not support a lot of SQL operations. A DBM > database consists of a single 'table' essentially. There is no reason that > you could not create multiple DBM files, of course, and treat them instead > as tables, but we're really getting ahead of ourselves! > > It sounds like an interesting project though, but I wonder about the > grammar for a SQL parser. Being a 'natural' language, it looks beastly to > parse. > > Out of curiosity, how would an SQL interface to an LDAP database work? > Aren't LDAP databases based on a different data model than relational > databases. Maybe I missed some irony. > > By the way, did anyone look at the code I had posted? It's pretty neat, > especially the multiple reader/writer test. You get a whole heap of > blocked readers/writers, which to me is pretty fun to watch as they each > fight it out for access. > > While I'm thinking about it, does anyone know how PHP really locks files? > There is supposed to be an advisory lock, and other PHP processes > obviously pay attention on the same machine. Suppose a script is running > across multiple servers sharing a single NFS export. NFS is supposed to > have poor native support for file locking, but is there something magic in > PHP that can keep things in sync? I haven't been able to deterministically > test with said multiple servers, so I don't know. > > Thanks > - Brent > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php