Re: 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