RE: [PEAR-DEV] DBM Compatibility layer

A query builder would make sense, and I think you're right that it is a better solution for both DB_ldap and dbm. - Stig On Fri, 2002-04-19 at 09:20, Lukas Smith wrote: > 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 > > > > > > > > >>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 > > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php