dbcook 0.2

framework to abstract database-mapping of objects/relations as python declarations, completely hiding the DB where possible
A framework for declarative mapping of object hierarchies/relations into a
(relational or not) database. Main idea is to abstract and hide the
DB-related stuff as much as possible, automate all (routine) DB-definition tasks,
still exposing the backend where abstracting is not needed/possible.

The "language/syntax" itself is DB-backend independent.
Currently the available builder is over SQLAlchemy as backend.

repository: svn co https://dbcook.svn.sf.net/svnroot/dbcook/trunk

Additions:
 * complete bitemporal class-mix-in : trunk/dbcook/misc/timed2/
 * (independent) automatic aggregating columns : trunk/dbcook/misc/aggregator*
 * (independent) metadata management (load,copy,diff): trunk/dbcook/misc/metadata/

Usage cases/levels:
 * DB-definition - completely hides/automates the table/ column/ key/ constraint/
    mapper/ whatever creation. The user can control certain characteristics of the way
    the mapping happens, mostly related to hierarchy and relations between objects
    (subclasses, instances, leafs, uniqueness etc).
 * generate a source of equivalent plain SQLAlchemy-calls to build the DB-definition -
    very useful for testing and/or generating routine mappings, with or without
    actualy using dbcook afterwards
 * use plain SQLAlchemy once the definition is done - e.g. session.query( class)..
 * can partialy abstract the query generation, converting from plain
    python functions/expressions (over objects' attributes) into backend/SQL clauses:
    ``lambda self: (self.friend.manager.age < 40) & self.name.endswith('a')``
 * writing own reflectors (that walk the declared classes and
    extract info from them), eventualy allowing different "language/syntax"

Features:
 * data column types - the actual mapping is separate from object declaration
 * reference columns - plain, forward-declared, self-referential -> foreign keys
 * automatic solving of cyclical references/ dependencies (proper alter_table / post_update)
 * class inheritance, class inclusion (inheritance without db-mapping of the base),
    and virtual classes (without instances). More in mapcontext._Base
 * polymorphism - 3 kinds of queries for each mapped class: all, base-only, subclasses only
 * any combination of table-inheritance-types within the tree -
    joined/ concrete/ no-single-yet - defined localy or hierarchicaly;
    beware that sql-polymorphism only works with joined-table for now
 * associations (many-to-many) - implicit and explicit
 * collections  (one-to-many)
 * dbcook.usage.samanager is a correct context-like keeper of all SQLAlchemy
    things in one place; on destroy() will try hard to clear _all_ side-effects of its
    existence, allowing reuse of same objects in several/different subsequent DB-mappings.

To use the framework, the internal dbcook/ has to be accessible somehow (PYTHONPATH or else).
Dependencies:
 * kjbuckets (from gadfly) for graph-arithmetics
 * SQLAlchemy, both 0.3 and 0.4

Example (see trunk/dbcook/usage/example/):
``
import dbcook.usage.plainwrap as o2r
class Text( o2r.Type): pass

class Address( Base):
    place = Text()

class Person( o2r.Base):
    name = Text()
    address = o2r.Type4Reference( Address)
    friend  = o2r.Type4Reference( 'Person')
    DBCOOK_has_instances = True

class Employee( Person):
    job = Text()
    DBCOOK_inheritance = 'joined'

#build it
o2r.Builder( metadata_from_sqlalchemy, locals(),
    fieldtype_mapper= { Text: sqlalchemy.String(100) } )
...
``
Not Logged In

dbcook 0.2
