Blocking on system setups (Wasting time trying to work around missing libraries...)
Written by
on
in
Snaking.
Have spent way too much of today on non-billable work that's basically just trying to work around not-yet-installed system libraries. Could probably have finished the task if I'd had a working environment. Of course, most of that wasted time is my own fault, should have just accepted that the libraries weren't there yet and moved on to some other task.
I did manage to prevent myself from writing an asynchronous PostgreSQL database adapter using ctypes, but it was touch and go for a few minutes there. After that I spent a while reflecting on one of Tim's comments regarding PyTable not being used by many people, so I sat down to look at using SQLObject instead.
It looks doable to refit full PyTable applications (such as Cinemon, those using a fully-specified schema) with SQLObject. Seem to lose the easy access to SQL queries (which I use extensively), but other than that the ORM features are about equal. It would be annoying to have to rewrite all of the property-aware code, but that would be doable. For the lower-level projects, ones that are not schema driven, it gets messier. Scripts that are effectively 2 or 3 highly parameterised queries using the PyTable's SQLQuery mechanism are going to be way more work to retrofit than any consistency would help. Apparently going to have problems with databases where we don't have simple integer sequence primary keys as well.
Which brings me back to the problem. SQLObject is a better ORM, but PyTable isn't really an ORM, it just has a few convenience methods for CRUD-style ORM operations and a richer SQL query-creation API than seen in the DB-API. Switching to using a full ORM may have benefits, but it really would be a complete rewrite of just about everything just to standardise on something widely accepted. The integration with the rest of BasicProperty (and all the code I have that uses the introspection that provides) would all be lost, so all of that introspective code would have to learn how to deal with SQLObject objects.
Anyway, I'm very much unconvinced that I want to leave PyTable, so maybe the solution is to work on popularising it? Or maybe it's working with SQLObject until it has the working methodology I want? Haven't even considered whether it can be used reasonably well within an asynchronous framework. Guess we'll see.
Comments
Comments are closed.
Pingbacks
Pingbacks are closed.
Rick Morrison on 02/15/2006 11:02 a.m. #
Hi Mike:<br />
<br />
If you haven't already, you may want to take a look at SQLAlchemy -- http://www.sqlalchemy.org<br />
<br />
There is a nice implementation of not only object-relational mapping, but a set of somewhat lower-level SQL query constructor routines that allow fairly fine control of query generation. Mike Beyer has done a great job with this, and the project looks as if it's about to really take off.<br />
<br />
The library doesn't seem to have direct support for asynchronous queries, but is apparently "thread aware", I'm currently looking into adding some kind of asynchronous query execution support that will play nice with the extant frameworks.<br />
<br />
Rick