Re: DBM Compatibility layer

On Fri, 2002-04-19 at 06:02, Brent Cook wrote: > > > 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. In fact, DB's query method is just a wrapper to simpleQuery that drivers don't implement. Take a look at DB_mysql for example. It may not be suitable for dbm, but it would be fun to see if it could work. > 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? The minimum set of methods that a DB driver must implemented are connect, disconnect, simpleQuery and freeResult. > 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. File_DB or File_DBM? > 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. It definitely is. Significant hubris is needed to take on this task. > 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. There is existing open-sourced code out there can be learned from or re-used. > 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. The query language is currently different for DB_ldap. > 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. Don't the free unixes have a working rpc.lockd yet? Locking over the network is a nightmare unless you have a server that supports locks that you can use. Such as MySQL for example :-) SRM could fill in this hole at some point I guess. If it doesn't support locks natively you are able to write a plug-in in PHP doing it. - Stig