Thanks Alex.
The ports of CL-SQL and Postmodern are the primary things holding up
the release process right now. If there are major issues there, I may
have to refactor my implementation. It would be really helpful to get
an ETA on a port and get the main and unstable branches integrated. I
just pulled all new patches from the main branch into the unstable
branch which, fortunately, wasn't too much work. The BDB store tests
pass for me locally.
My goal is to build momentum towards a 1.0 release given that the
current functionality seems to be getting good traction and is holding
up well under real-world use. That will give us a stable platform
that people can depend on being kept up to date with bug fixes and
also give us some freedom from developing any major new features for
awhile. To this end, I'd like to produce a beta candidate (1.0b1) as
soon as the back-ends are ported and we've updated the test suite a bit.
The upgrade should be pretty easy, I tried to touch the data store API
as little as possible. Here are some pointers from my e-mail of
3/23/08:
FYI - The backend updates will require:
UPDATE STORE CONTROLLER (trivial)
- Initialization of store-controller base class slots with btrees that
have static oids
(schema-table :reader controller-schema-table
:documentation "Schema id to schema table, an indexed btree")
(instance-table :reader controller-instance-table
:documentation "Contains indexed btree of oid to class ids")
(index-table :reader controller-index-table
:documentation
"This is another root for class indexing that is
also a data store specific persistent btree instance
with a unique OID that persists between sessions.
No cache is needed because we cache in the class slots.")
BOOKKEEPING FOR SCHEMA IDS (should be easy)
- next-cid (sequence of schema id values)
- specialize oid->schema-id (accounts for reserved oids for the fixed
btrees above)
- default-class-id (map class typename to class schema id for reserved
types)
- default-class-id-type (map class schema id to class type name for
reserved types)
DUPLICATE BTREES (this is the only part that may be tricky)
- Implement duplicate btrees (allow duplicate keys ordered by key,
value)
- add remove-kv-pair operator to augment remove-kv
For examples of all of the above see bdb-controller and bdb-collections.
I may be forgetting something, but these are the main items.
Thank you,
Ian
On May 3, 2008, at 10:02 AM, Alex Mizrahi wrote:
IE> but we haven't had any work done on this in Postmodern yet.
by the way, are there any people waiting for postmodern being
ported, or is it causing any problems if it's not ported yet (i.e.
delaying release or something)?
because for now projects i'm working on seem to be working more-or-
less good as they are,
and there is no big need to move them onto new elephant version --
there are other things to do.
but if some people are waiting for it, i can at least check how hard
this porting will be, and actually port if it will be easy.
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
