PyTable?

Mike C. Fletcher mcfletch at rogers.com
Mon Mar 1 17:25:02 EST 2004


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/






More information about the Python-list mailing list