[PEAK] The path of model and storage

[Robert Brewer]

Phillip:
> For multithreaded scenarios, the idea is that you use an "application 
> pool".  An application pool is just a list of zero or more top-level 
> application objects.  When a worker thread picks up a request,
> it also pops an application from the pool, or creates a fresh
> instance if the pool is empty.  At the end of the request,
> the worker thread returns whatever application instance it
> used to the pool (via pool.append()).

My turn to say "ah". :) I do the same thing with sandboxes, which are
one step below top-level but perform the same function.

> Last, but not least, I should note that use of threads in Python 
> applications is in general more of a way to *burn* processor 
> time than to save it.  Don't forget the GIL!

Of course. But when you write a webapp with, e.g. mod_python, threads
are a given. Somebody has to deal with them at some point.

> Hm.  If that dynamic page is *really* the same, then shouldn't
web-tier 
> caching (e.g. via the Expires: header) be able to handle some of that?
Or 
> for that matter, why not build a static page and redirect to it?

They never are *really* the same, are they...? Marketing always wants
"your name here" (or other 'personalized' messages).

> Actually, my experience has been that for Python web 
> applications, page *rendering* (i.e. the string processing
> to create the page) dominates response time in the common case.
> If database retrieval and conversion to objects dominates response
> time, it seems likely that there's a problem with your database!
> (Or the application is not making optimal use of the database.)

There are several factors, of course. Once you 'solve' for one, you find
another is the new bottleneck. I readily admit I'm squeezing the last
few drops out of the performance orange. :)

> A mapping layer directs the transformation from abstract 
> model classes to concrete implementation classes, and
> registers operations with the workspace's generic functions
> to perform all necessary loading, saving, cache management, etc.

I'm still rolling this one around in my head. I've encountered a great
many ORM designers at one extreme, who feel that the DM can do all of
that without having to create any "transformed classes"--the model is
always 'abstract'. They tend to be those who have complete and
monopolistic control over their data. ;) I happen to have a strong
current use case for a more moderate position, where 2/3 of my data does
very well with a generic DM, but the other third needs such a mapping
layer. I took the approach of writing a bridge (wrapper) for that third
(another process which serves domain objects over a socket). You seem to
be taking the opposite extreme in that every (concrete) domain object
instance has the persistence mechanism built into it...?

> If a mapping layer can determine everything it needs to know from 
> the model classes, it will not need a schema.  But e.g. a relational 
> database mapping layer will need a schema to configure it.  (Whereas
> a mapping layer that reads and writes XMI files might not need any
> data but the classes themselves.)

Ah. So one possible concrete implementation class will be the abstract
model class?

Thanks for the reply! I'm learning a lot. :)


Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org