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