On Apr 28, 2009, at 12:43 PM, Paul Rigor (gmail) wrote:
> Hi, > > The support for relational databases seems to be tightly coupled to > mysql (Please correct me if I'm wrong). In sqlgraph.py for example, > database connection defaults to mysql with an explicit import of > MySQLdb, search for mysql configuration file variants, etc. In Pygr 0.7 and before, only MySQL was supported. 0.8 provides a mechanism for handling the SQL variations of different database servers, and adds sqlite support as a first example of that. The old mechanisms for connecting to the database server are gradually being deprecated in favor of the new ServerInfo mechanism (a pickleable database connection object), which is totally general. > > Wouldn't a package like SQLalchemy provide a more transparent way of > accessing a relational database backend? This package can handle > several database 'engines' and provide a common interface to work > with. Jenny Qian did an analysis of this a while back. You can see that meaty discussion here: http://groups.google.com/group/pygr-dev/browse_thread/thread/a251addd179531e5/1cade214145543de?lnk=gst&q=sqlalchemy#1cade214145543de Pygr's goal is to be agnostic about back ends (i.e. work with any back- end without prejudice). So adding support for working with SQLAlchemy would be great. The question is whether we can *eliminate our own support* for SQL back-ends by switching to SQLAlchemy. AFAIK, the main problem is a major difference in philosophies. - Pygr follows a "pickling" model, i.e. to access an existing resource, *no user code whatsoever* should be required, by the user simply "saying the name" of the desired resource, it should be automatically loaded, with all its relations to other data resources intact. I don't think SQLAlchemy database objects are pickleable in this way. - there are bunch of other issues surrounding the general Pygr philosophy of providing a consistent graph interface to all data, with automatic schema relations etc. I would be very interested if you see a way to make a SQLAlchemy interface pickleable, so that it could be saved to pygr.Data. > > I'm still a bit unsure whether pygr actually uses the db uri stored > in the PYGRDATAPATH environment variable to obtain the connection > string. For sure a metabase object is instantiated with the correct > 'dbpath', but that object doesn't seem to parse that dbpath > parameter. Also, In loading the 'metabases', there is no way to > explicitly specify connection parameters (user, host, password, port). Actually, you can specify host user password in the PYGRDATAPATH. From the docs for SQLTable: "If cursor is None, it will attempt to connect to a MySQL server using authentication information either from your the name string (treated as a whitespace separated list in the form tablename host user passwd; at least tablename and host must be present)..." metabase uses the same syntax. We could add port easily to this list. Sometime soon metabase will switch to using SQLTable explicitly, which will make the (current) MySQLMetabase backend compatible with sqlite (and other database servers if we add SQLTable support for them). This would get rid of the annoying path syntaxes (such as that above) and employ a really clean mechanism based on the general concept of ServerInfo (i.e. a pickleable reference to a database). In other words, a connection to a database would itself be a resource saved in pygr.Data. Officially, this kind of focus on development of pygr.Data is supposed to happen in release 1.0. But if users like you push for it, it could be done soon. > > I guess I'm still a little confused and I'm learning by placing > print statements all over the place... Sorry! Updating the docs for 0.8 is high on my list of to-do's... -- Chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to pygr-dev@googlegroups.com To unsubscribe from this group, send email to pygr-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
