python persistence

[castironpi at gmail.com]

On Apr 1, 11:34 am, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
wrote:
> En Tue, 01 Apr 2008 08:47:33 -0300, <castiro... at gmail.com> escribió:
>
> >> >>>> c['0']= type('None',(),{})
> >> > Traceback (most recent call last):
> >> > pickle.PicklingError: Can't pickle <class '__main__.None'>: it's not
> >> > found as __main__.None
>
> >> Don't do that then. Or use the available pickle hooks to customize how  
> >> such classes may be pickled. All persistence mechanisms have  
> >> limitations.
>
> > I don't see a problem with that; except that binaries come from
> > disks.  You could have a Python session that runs entirely on disks +
> > the ALU.
>
> (ALU? Do you mean CPU?) I don't understand this. Most programs are read  
>  from disk. Most data is read from disk.
>
> > I want to know if any, and correct me here, simple
> > modification can store live objects.  I call a.append(it) and the
> > memory update takes place on disk instead.
>
> Using ZODB, a.append(it) would mark `a` as dirty. When you latter commit  
> the transaction, it is stored back on disk.
>
> > If you require that all objects referenced by on-disk objects be on-
> > disk, that's an easy workaround.
>
> ZODB already does that.

It's pretty close, but the database connection can get bulky.  If you
had:
 _______________________
|         ______________________
|File    | PyOb1 | PyOb2 |  ..  |
|        |_______|_______|______|
|_______________________

on disk, updating the reference counts and attributes would take a
long time, but it's just right for some core applications.

Strictly, I'm not in the "real" programming world, so if it's just a
few free steps to a database then I'm speculating.  If it's not, then
writing database code needlessly complicates programs in some cases.
A default implementation might even take an explicit destroy
statement, essentially being a run-time swap file or random-access
pickles.

A possibility is to launch a manager in a separate process, so authors
don't have to bother with writeback.  I'm actually almost looking at
off-loading protocols on this one.  Cache is guaranteed to be up to
date, so cache a file in memory, and manipulate it so it has Python
bits.  The object comes to survive the program.  Call stack is still
in volatile.

> Using ZODB, a.append(it) would mark `a` as dirty. When you latter commit
> the transaction, it is stored back on disk.

Python changes are committed on line.  ZODB does -not- do that.  A
pretty close change would be:

Open file
Interpret file as generator, halted at yield but started,
Call send and next

What does the code for that look like?