pcplantdb

[Chad Knepp <pyg@galatea.org>]

OTE and on and on.  Finally sitting down to hack and here is where I'm
at: I'm currently doing a bit of backtracking that is disappointing to
me personally.  The issue is that I'm running into a time deadline
that involves me really understanding the interactions between Zopes
__bobo_traverse__ and acquisition.  I've been trying to implement some
virtuality in the object manager to generate a readable/hackable url
so something like piw/plant/42 or piw/plant/okra would return the okra
root object.  As I said I think I'm running into a time issue in that
I don't have enough time to figure these particular intricate little
Zope issues out.  What I was trying to do is not common enough for me
to find good examples.  My compromise solution simply means that the
url won't be as meaningful.  Anway, I think I can rewrite the object
manager with a single BTree which is a sufficient implementation
performance wise, but objects will just be referenced by a long
interger something like piw/42 returns some object that could be the
root level object of okra.  In terms of lessons I learned I think I
was trying to do too much...  My current goals rewriting the object
manager to return root level objects by tonight.  I'm also claiming
this experience for education and will starting billable hours when I
have a working object manager.  The last day in my hours file is
Sept. 22nd, both because I haven't been able to get much time in (busy
sorghum season) and I don't feel I've done work that has resulted in
forward progress since then.  I have this next week almost entirely
free except for a small amout of domestics so I think these next
couple of days can be productive.  Sorry for being so flaky.

Here is a little bit on the HG data model mostly for the geeks.

The core of the HG data model implementation is a doubly linked tree
structure which is stored in a Balanced Tree (B+ implemented in C),
something that is necessary for the possibly 100 million objects or so
we could scale too.  At the root level is a on object that identifies
the element and points to child objects.  In actuality any object can
be a root level object but some root level objects have no parents.
The level of distinction between parentless objects determines the
granularity of the dataset, but could be anything from family to
cultivar.  Alot of my design questions in the past have been about the
level of granularity our dataset should have.

Anyway, parentless objects are the highest level of objects in the
data model and their primary role is to identify the type of
information within it.  Children of the parentless objects can be
anything but for plants will probably consist of things like
localized/common names, description with localized variations,
cultural information, propagation information, etc.  Things like
comments, ownership, and editing information can be attached to
absolutely any other object, esp. including comments.  Relationships
will be root level objects and will relate an two sets of objects and
subobjects.  All objects will provide methods for search traversals,
etc. 

Off to play,
Chad

-- 
Chad Knepp
perl -e 'print pack"H*","7079674067616c617465612e6f72670a"'