persistent composites

[Aaron Brady]

On Jun 17, 3:53 pm, "Rhodri James" <rho... at wildebst.demon.co.uk>
wrote:
> On Wed, 17 Jun 2009 16:06:22 +0100, Aaron Brady <castiro... at gmail.com>  
> wrote:
>
>
>
> > On Jun 16, 10:09 am, Mike Kazantsev <mk.frag... at gmail.com> wrote:
> >> On Tue, 16 Jun 2009 06:57:13 -0700 (PDT)
>
> >> Aaron Brady <castiro... at gmail.com> wrote:
> >> > Making the charitable interpretation that this was the extent of c-l-
> >> > py's support and enthusiasm for my idea, I will now go into mourning.
> >> > Death occurred at oh-eight-hundred.  Rest in peace, support &
> >> > enthusiasm.
>
> >> I've read this thread from the beginning, being tempted to insert
> >> remarks about shelve module or ORMs like SQLAlchemy, but that'd be
> >> meaningless without the problem description, which I haven't seen
> >> anywhere. Is it some trick idea like "let's walk on our heads"?
>
> > More like bronze them, or hang them on a tackboard.  You haven't
> > convinced me that it's not a problem, or that it's an easy one.
>
> Unfortunately it's up to you to demonstrate that it is a problem,
> whichever of the many possible 'it's you're talking about.  So far,
> the question "Why would I want to use this?  What's the use case?"
> has gone unanswered, and I'm sure I'm not the only baffled by it.

I can demonstrate it's a problem; many things are.

The subject line says it all.  SQL will persist (and share for IPC,
after a fashion) sets of statically typed tuples.  But we have need
for sets of dynamically typed tuples, in volatile storage at the very
least, or no one would like Python.

Whether we have need for them in persistent storage remains to be
seen.

POSH Python Object SHaring has been at least one student's graduate
thesis.  It couldn't hurt to pursue it if one has time, as with many
things.  It's pretty likely my estimates of end user usefulness of
'KeepDB', say, derive sturdily and steadily from our estimated
popularity of Python.  So much for my motives, though not for my
opportunities.

My implementation has followed two separate paths: one using SQL for a
back-end host; the other using hand-coded bytes on disk, complete with
large file support using views, and on-disk (or in-buffer) memory
management, which incidentally I spoke up about about a year ago.  It
was the topic of an honors lecture in the Data Structures course in my
undergrad.  For the record, I still can't beat a log-N balanced tree
for finding free nodes, but I am operating on the assumption that the
smallest sufficient region is the best to return from 'alloc'.

You are not being any help, Rhodri, in your question.  Its chief
virtue is fidelity of programming, that is, what you write is most
true to what you mean.  If you have an object on disk, and want the
third element of its 'coords' list attribute, it's a waste to do
anything other than find its disk address, then the disk address of
its 'coords' attribute, then the disk address of the third element of
that, such as say, loading or worse, processing, the entire structure;
even if, and in light of parallel considerations about economic market
transparency and efficiency, that is to say, economy, maybe /
especially/ if, you are having a lowly machine make do.  You don't
want to open every box in your basement to find your tennis racket;
you want to open one box, find the racket in the index, then open all
and only the boxes that 'nestedly' contain the racket.  (Yes, that's /
all/ and /only/, or 'if and only if'-- not to be confused with 'one
and only'.)

It's more economic.