Relative independence of odbs: IndexedCollection, the update problem

Sebastian Sastre ssastre at seaswork.com.ar
Sat Sep 25 13:45:24 UTC 2004


Hi all, 
 
    I'm trying to make  a solution for the following problem:
 
    "Minimize the impact of the software you make in a future change of
the ODB schema."
 
    Until now, I've found this specifical features needed (perhaps you
can review/add more):
 
    Requeriment: To have solved in one place a big ammount of persisted
objects, that could be accessed efficiently by different "attributes"
(supporting wilcards), in a simultaneous, sustainable, transparent and
easily maintainable way. All this together.
 
    1. Big ammount of persistent objects. At first view any collection
could have them, but as they are to be persistent, they need to be on an
apropiated support. A BTree or TSTree satisfies this requirement.
 
    2. Accessed efficiently. Those trees access their content very
efficiently. Specially TSTree for wilcarded text searches.
 
    3. Different attributes. For each attribute that the persistent
objects is wanted to be searcheable, it's needed one of those trees. Let
me call this indexing. So, this trees wil have in their keys, the values
(probably restricted only to integers and strings) of the "attribute" of
the objects stored, and in their values the objects itself. A tree for
each indexed "attribute". This collection of trees may have the know how
to maintain them and hold them. I called it IndexedCollection.
 
    4. Wildcards search support. The TSTree supports wilcarded strings
searches. Perhaps BTree too, in near future. In OmniBase, any ODBTree
also support this.
 
    5. In simultaneous way. This IndexedCollection may have a friendly
protocol for adding index, removing index, and querying on any index at
any time.
 
    6. In Sustainable way. The changes of an element of the collection,
should be updated in the respective index if matters (the update
problem). In other words: the index should allways have it's keys
synchronized with the objects attributes values.
 
    7. In transparent way. That the elements should not perceive that
they are persistent. I mean, they should not need to have any method nor
code to update the indexes or anything related to the persistent schema.

 
    8. Easily maintainable. That one can add or remove indexes as one
needs.
 
    9. All together. To have all this togethter in one place: a special
collection that support all this features at one time, here I called it
IndexedCollection.
 
    If you know Magma I'm talking about serveral of the
MagmaCollection's features, plus some others like having independence of
the persistent schema itself. It's some kind of generalization that will
be useful to you to develop software that need persistence, minimizing
the impact of (for ANY reason) a change of the odb schema/vendor.
 
    The main problem right now it's the update problem (point 6). When
anyone changes the value of an indexed attribute of a persistent object,
it should exist some kind of triggering mechanism, so the
IndexedCollection could tell to the corresponding index, to update it's
key and value corresponding to the mutating element.
 
    Hypothesis: what about making some kind of proxy or wrapper to every
element you add to this collection, to monitor (via DNU) every message
sent to the monitored element, and when appropiate, trigger the change
of the target attributes, so the collection could update it's indexes?
    
    In that case, we have to solve the additional problem of the change
of domain: the ODB domain to VM domain, and vice versa. That will drop
the identity of the objects, including elements, wrappers, the hooked
events, and the collection itself. So here is the problem. I'm thinking
about it for several days without enlightenment yet. Any idea to solve
this? Any better idea/strategy?
 
    best regards,
    
Sebastián Sastre
HYPERLINK "mailto:ssastre at seaswork.com.ar"ssastre at seaswork.com.ar
HYPERLINK "http://www.seaswork.com.ar/"www.seaswork.com.ar
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.767 / Virus Database: 514 - Release Date: 21/09/2004
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040925/cbb3dc5e/attachment.htm


More information about the Squeak-dev mailing list