I remember back to a VB.NET course I took quite some time ago, the instructor made a comment in the first class to the effect that “all real applications use a database”. That wasn’t a surprising comment and it actually reflects most of the projects we take on, although I’ll have to stick with a classic definition of database to mean more than just relational.
With a few years under our belts using Python for scheduling “things that go bump in the night” type processes we’ve seen our fair share of weirdness on the back-end setups of client shops and (this may come as no surprise) an oddly high amount of downtime from data providers (sans outages notices might I add).
Most of our hard core data manipulation programs utilize some type of read or write from a proprietary or public data model (implemented in a pure form or with extensions). In any case, we end up using the Python DB-API modules that are made available online, a variety are available and depend upon the underlying database engine. If you read through the Python DB-API specification you’ll see what is indeed mandatory and what other syntax sugar can be added. There are some modules out there that have a plethora of additional capabilities (most of which works!) and I’ll give them credit for not stomping to hard on the DB-API.
We spend much of our time working with ESRI specific databases and data formats and with their commitment to Python over the next few major releases of ArcGIS we’d sure like to see them become more standardized in their Python approaches, for example, up until 9.3 it was tough to consider anything Pythonic in their implementation. Now with 9.3 we see that they are taking it serious and working to improve their use of POPOs. One step further (and this should be relatively straight forward for the development team at ESRI) would be to implement a proper DB-API that at a minimum implements the required components of the DB-API and then adds spatial capability as well.
For those that are interested we’ve already been working on a Python module to allow such “expected” capability. Most of the individual components are written and next steps are to collate the components into the expected DB-API form.
No Comments Yet so far
Leave a comment
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <pre> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>