Hi,
I've been reading SA docs (congratulations on them btw) and some of
the code.
There are a few things I'll need to solve to integrate SQLAlchemy in
my Zope application. I'd welcome your comments.
1. I'd like the possibility of having the identity map not cleared on
commit. This turns identity maps into proper cross-requests caches in
the context of web applications. This is what ZODB does, and it's
extremely beneficial to have non-modified objects kept in caches
associated to a pool.
Of course this needs a proper system of cross-thread invalidation,
when a thread commits it has to inform all other threads that the
object with a given database identity has changed (Zope's ZEO also
uses this for cluster invalidations, using ZEO as an invalidation
server that redispatches to all connected clients).
2. I'd like to replace the identity map implementation with another
one derived from Zope's ZODB (the persistent.PickleCache, coded in C).
PickleCache has a number of very interesting features, most notably
automatic size management with a target maximum size, the rest may be
garbage collected (LRU eviction). It has one constraint, which is
that the database identity is stored in a _p_oid attribute that must
be a string.
I'm not sure yet where I must plug or what I must refactor in SA to
get this.
3. In some cases, I'd like the option of assigning a mapper to a
class differently, without any class modification. I would inform the
history/attributemanager system that something changed on the object
by other means than monkey-patched properties.
I'd like to use this to minimize class disruption, and to instances
(I'm not sure what's set on an instance when it's modified). ZODB's
peristent.Persistent base class (coded in C too) has a system whereby
any object modified by direct attribute access can register itself as
modified with a manager, and if possible I'd like to reuse this (note
that it has a coarser granularity than knowing exactly what attribute
was changed, it just knows that one object is modified or not).
4. Another interesting feature of the persistent.Persistent class is
the notion of "ghost". A ghost is a stub for an object that's lazily
loaded. It has a very small memory footprint. On any attribute
access, its manager (_p_jar) is called to fetch the object's state.
Conversely, when the PickleCache is purged by the LRU mechanism, old
entries are not deleted but turned back into ghosts.
I'm not sure if this could be beneficial but is a side effect of the
Persistent class I'll have to manage in conjunction with SA.
5. I'll have to add two-phase commit to SA because this is essential
to Zope's transaction mechanism (which may manage several databases).
6. I'd like to hook somewhere to provide filesystem storage of some
classes' attributes instead of having them mapped to the RDB. I'd use
this for images and attached files, where I'd rather use NFS storage
than transmit a blob through SQL.
I'm not familiar enough (yet) with SA's code to know if these points
are complex to do or already possible. Advice welcome.
I can provide more details about ZODB's features if needed.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
