[sc34wg3] Possible TMRM issue

[Jan Algermissen]

Hi Lars,

On Mar 20, 2006, at 1:51 PM, Lars Marius Garshol wrote:

> What we need is some kind of reassurance that it is *possible* to  
> implement this efficiently.

I think you need to sort out first, if the RM is meant to be  
implementable in the abstract sense or if only applications of it  
(e.g. TMDM) have to be implementable.

I think Steve and Patrick think the latter.

If it is the latter case then implementations can use the additional  
semantics to build the neccessary indexes.

FWIW, I did implement a former version of the RM. I am not sure how  
much the model changed since then but I had the same issue back then.  
I solved it by adding the constraint that properties have to have  
fixed value types and that value type dependent plugins needed to be  
supplied. This solved the underlying problem that you can only  
implement efficient storage and indexes when you know the data type.

And you need the indexes to do merging in O(log n) time. It is I  
guess the most complex thing I ever did, but it worked and scaled.

The tricky thing is that property values can contain proxies  
(assuming it still works that way), and that merges of proxies cause  
changes to property values that in turn can (and often will) lead to  
further pending merges.

I still have the code if anyone wants it.

Jan



________________________________________________________________________ 
_______________
Jan Algermissen, Consultant & Programmer                         
http://jalgermissen.com
Tugboat Consulting, 'Applying Web technology to enterprise IT'   
http://www.tugboat.de