PyTable?

C

Chris McAvoy

Hi,

I was looking at PyTable this morning, after seeing it on PythonWare's
Daily Links page. It's interesting, because my local Perl Monger's
group is having a talk on Class::DBI tomorrow night, and they sound
very similar. I can't attend the talk tomorrow, so thought I'd ask
something here.

What are these two modules about? Another abstraction layer for the
DB? I've never heard of this as a concept until today, and I'm a
little lost. Are they mimicing functionality available in another
language that I'm not aware of?

PyTable points to another module called BasicProperty that abstracts a
Class?

Could someone help me wrap my head around what appears to be a new
"trend"?

Thanks,
Chris
 
M

Mike C. Fletcher

Chris McAvoy wrote:
....
What are these two modules about? Another abstraction layer for the
DB? I've never heard of this as a concept until today, and I'm a
little lost. Are they mimicing functionality available in another
language that I'm not aware of?

PyTable points to another module called BasicProperty that abstracts a
Class?

Could someone help me wrap my head around what appears to be a new
"trend"?
Will try, though since I authored the sites that confused you I may not
be the best person to try. First of all, I can't really say anything
about the Perl module, as I don't use Perl. I'll just stick to what
PyTable does.

PyTable's primary strength is its schema-driven nature. A database plan
(schema) is created which maps the structure of the database into a
run-time introspectable data structure.

Normally the schema is created in Python code, and used to drive the
creation of the database, (though facilities are available for
extracting a basic schema from the database). The schema can include
information regarding what classes to instantiate when retrieving
records for a given table (with suitable defaults provided). The schema
is used internally by DBRow objects to implement update and insert
queries, for instance. In other words, the DBRow objects can look at
themselves to decide what actually needs to be done to accomplish a
given task (such as specifying their row uniquely in the table).

PyTable sits halfway between the raw DB-API (where you know only
approximate data-type, name, and a few other minimal pieces of
information) and a system such as PDO (where the database interactions
are done through an object-oriented API). PyTable is still very much
about generating and running SQL code, you are not forced into the
"everything is an object" mould, you can still run raw SQL (with some
helper mechanisms to make creating complex queries easier) and integrate
those queries into your row classes. The PyTable DBRow objects are
simply very rich introspectable wrappers around the DB-API records (you
can use non-DBRow records too).

As to BasicProperty, its purpose is to allow for defining rich
"attribute descriptors", similar to the property objects built in to
Python 2.2 and above. Distinction being that the BasicProperty
descriptors are far more involved, including default values/functions,
two levels of storage hooks for customizing behaviour, the ability to
auto-coerce values to/from data-types on save/restore, support for
list-of types etceteras. BasicProperty is an extremely general
mechanism, so it's a little hard to say what particular benefit it has
without looking at particular applications.

* In PyTable, the field descriptors are actually BasicProperty
objects linked to the field schema for the table from which they
were created, so they can, for instance, be used to lookup foreign
keys (and their tables)
* In PyTable's internal machinery, just about everything is a
propertied object. This allows for defining objects as a
collection of properties with documentation, default-values,
data-typing and coercion. There are very few "__init__" methods,
as just about everything uses the same base class which provides
simple property-aware initialisation. Adding/removing properties
generally doesn't require any change to the code other than the
actual property declaration.

Back to the subject at hand; In effect, PyTable is about trying to make
the nitty-gritty details of dealing with an SQL-driven application
easier by providing introspection facilities that let your code reason
about the structure of the database (as embodied in the schema objects).

What PyTable is not:

* Lightweight: compared to db_row or the like, it's very
heavyweight, focused on creating interactive apps, not huge
back-end processing apps that need to realise millions of rows
simultaneously
* An SQL abstraction mechanism: unlike PyDO no attempt is made to
define a common SQL sub-set, i.e. it's not like ADO from Microsoft
* An object-relational mapper: though it may seem like it, PyTable
doesn't convert references to records automatically (unless you
explicitly code a property to do so), it doesn't map pivot tables
to pseudo-dictionaries, in general, it only executes the SQL you
tell it to execute
* Finished: there's still a lot of work to do to get to 1.0 beta 1
for PyTable

Anyway, hope this helped somewhat. Have fun,
Mike

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,048
Latest member
verona

Latest Threads

Top