<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Mensaje</TITLE>
<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana size=2>Hi all,
</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>I'm trying to make a solution for the following
problem:</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>"Minimize the impact of the software you make in a future change of the
ODB schema."</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>Until now, I've found this specifical features needed (perhaps you can
review/add more):</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>2. Accessed efficiently. Those trees access their content very
efficiently. Specially TSTree for wilcarded text searches.</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>4. Wildcards search support. The TSTree supports wilcarded strings
searches. Perhaps BTree too, in near future. In OmniBase, any ODBTree also
support this.</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>5. In simultaneous way. This IndexedCollection may have a friendly
protocol for adding index, removing index, and querying on any index at any
time.</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>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.
</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>8. Easily maintainable. That one can add or remove indexes as one
needs.</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana size=2>
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.</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>Hypothesis: </FONT></SPAN><SPAN class=531471812-25092004><FONT
face=Verdana size=2>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?</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana size=2>
</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana size=2>
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?</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004><FONT face=Verdana
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=531471812-25092004> <FONT face=Verdana
size=2>best regards,</FONT></SPAN></DIV>
<DIV><SPAN class=531471812-25092004> </SPAN><FONT
face=Verdana size=2></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Verdana size=2>Sebastián Sastre</FONT></DIV>
<DIV dir=ltr align=left><FONT face=Verdana size=2><A
href="mailto:ssastre@seaswork.com.ar">ssastre@seaswork.com.ar</A></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Verdana size=2><A
href="http://www.seaswork.com.ar/">www.seaswork.com.ar</A></FONT></DIV>
<DIV><FONT face=Verdana size=2></FONT> </DIV></BODY></HTML>
<BR>
<P><FONT SIZE=2>---<BR>
Outgoing mail is certified Virus Free.<BR>
Checked by AVG anti-virus system (http://www.grisoft.com).<BR>
Version: 6.0.767 / Virus Database: 514 - Release Date: 21/09/2004<BR>
</FONT> </P>