[TransWarp] HowTo TreeBased Storage with RecordManagers / Specialists ??

Ulrich Eck ueck at net-labs.de
Fri May 10 12:19:42 EDT 2002

Hi Phillip,

>> I'm working on my Workflow Engine, that should store it's data in an
>> LDAP-Directory.
> I'm curious why something as complex as an LDAP directory, as opposed to
> something simple, like text files.  :)
Why do something simple .. if there is a more complex way to do it :)))

.. no .. this is just some exercise for our Active-Directory-Management
System, where we will need the features described below ...

I already have XML Import/Export and DataStorage in StandaloneZODB right
now. We want to build a system where Workflow's can be modified/extended
dynamically .. so there would be much effort to to this with plain text 
files ..

>> so i would place Specialists into Elements, and the behaviour of them
>> would depend on the Element's
>> data. I would need to modify the Specialists code to make the
>> keyConstants  dynamic .. which should not be too hard i think.
>> Is there a better way to achieve Tree-like storage using TW.Database
>> (especially LDAPModel) ??
> Yes, definitely, if by better you mean "preserves the abstraction of the
> storage layer".

yes .. that was what i meant.

> Set up the specialists in the conventional way using unique keys (either
> generated, or the DN).  Define features that refer to collections of
> child items.  Add "domain-specific query" methods to the specialists and
> to the LDAPModel that return a list of items which are the child of some
> other item.  Have the feature call the Specialist's method to return its
> collection, and the Specialist of course will call the LDAPModel.
> More specifically...  Let's say you want to get field definitions for a
> process.  Add to your RecordType a method getFieldDefsForProcess() which
> takes the DN or unique ID of the process, and searches for records in the
> LDAP directory.  It can then map each result into a Record object, using
> the same techniques as a single-record query does.  It then returns a
> collection of Record objects.
> The specialist for field definitions will also have a
> getFieldDefsForProcess() method, which will call the LDAP model and wrap
> the records in Elements, using its cache to ensure that it returns
> existing Elements if available.
> Finally, create a collection feature "dataFields" in the Process element
> class which retrieves its value by calling the specialist's
> getFieldDefsForProcess() method.
> Admittedly, this process probably involves a bit more coding than you had
> in mind.  This is mainly because I haven't done any of these myself yet,
> and so I haven't yet added helper methods to Specialists, Features, and
> RecordTypes to do the grunt work of these things for you.

This sound's doable to me .. but I still have one open question:

- Would your solution be the same if i would store data in an RDBMS using
  tables with muliple fields as key ?? (e.g. 

I really want to build all these Services Storage-independent as fas as 

thanks for comments .... (p.s. if there is anything i can help you, getting 
closer to 0.2 (except testing .. what I'm doing day by day) , please let me 
know and
i'll try to spend some time for this if I'm able to)

Ulrich Eck
net-labs Systemhaus GmbH
Ebersberger Str. 46
85570 Markt Schwaben
fon:   +49-8121-4747-11
fax:   +49-8121-4747-77
email: ueck at net-labs.de

More information about the PEAK mailing list