persistent composites

[Aaron Brady]

On Jun 15, 8:37 am, a... at pythoncraft.com (Aahz) wrote:
> In article <79mtt7F1r480... at mid.uni-berlin.de>,
> Diez B. Roggisch <de... at nospam.web.de> wrote:
>
> >Aaron Brady wrote:
>
> >> Some time ago, I recommended a pursuit of keeping 'persistent
> >> composite' types on disk, to be read and updated at other times by
> >> other processes.  Databases provide this functionality, with the
> >> exception that field types in any given table are required to be
> >> uniform.  Python has no such restriction.
>
> >> I tried out an implementation of composite collections, specifically
> >> lists, sets, and dicts, using 'sqlite3' as a persistence back-end.
> >> It's significantly slower, but we might argue that attempting to do it
> >> by hand classifies as a premature optimization; it is easy to optimize
> >> debugged code.
>
> >Sounds like you are re-inventing the ZODB.
>
> ...or SQLAlchemy or pickles in a SQL BLOB or...

I recognize your aversion to my claim of making a new approach on
something.  I suppose an austere review of literature would compare
with the existing alternatives.

My approach does not define tables, so it is not SQL Alchemy; it is
not mere sugar for SQL.  It defines a 'set' class and a 'tuple' class,
so some of the functionality may (and probably should be expected to)
overlap.

http://www.sqlalchemy.org/docs/05/ormtutorial.html#define-and-create-a-table

My approach does not pickle objects, so it is not a mere BLOB pickle.
If a user writes, listA[ 50 ].append( "abcde" ), one addition is made
to an existing structure, and the remaining contents of 'listA' are
unread and unchanged.