Typerel cleaning
Called by:Michiel Meeuwissen
Total tally on this call : +8
YEA (8) : Nico Klasens, Eduard Witteveen, Rob Vermeulen, Pierre van Rooden, Rico Jansen, Kees Jongenburger, Gerard van Enk, Wilbert Hengst
ABSTAIN (1) : Rob van Maris
NAY (0) :
VETO (0) :
No votes, assumed abstained (6): Daniel Ockeloen, Marcel Maatkamp, David van Zeventer, Mark Huijser, Johannes Verelst, Jaco de Groot
Call result:
Call succeeded, code can be changed.
Michiel Meeuwissen wrote:
Call for:
TypeRel cleaning and inheritance support
Description: ========================================
Currently the typerel builder's getAllowedRelations function does not
take into account the new 'inheritance' features of MMBase.
While exploring how difficult it would be to add support for this in
TypeRel, I ran into the other issue, being that the current typerel
implementation got a little messy. We count for example 3 seperate
caches in it, and a bunch of private methods which try to keep those
in sync with the actual situation.
Several functions of TypeRel also do database queries sometimes if
that seems to be necessary to give the right result
(getAllowedRelations, reldefCorrect), and the result is then stored in
the hashtables to avoid this next time.
My proposal it to rewrite this drasticly. Throw away all those
hashtable caches (one is lru), and replace it with one, which simply
should contain every TypeRel node. FurtherMore it should contain
'virtual' typerel nodes which reflect relations only possible because
of inheritance.
All public functions then can be rewritten, using only this
cache. This cache is implemented as a Set of MMObjectNodes (since most
functions need to return Enumerations of MMObjectNodes). To make such
an implementation efficient, to MMObjectNode and MMObjectBuilder must
be added hashCode and equals functions (e.g. a 'VirtualTypeRelNode'
must be equal to an actual typerel MMObjectNode if they reprsent the
same relation type). Checking if a relation is possible can then be
implementated completely straightforward, just by checking if the Set
contains the right node. Searching with a source can be done with a
subSet operation.
Impact
========================================
Typically this cache should not become very large. VPRO (perhaps a
good estimation of the upper-limit) has 676 typerel entries in
database now. So, after this hack there will be about that much
MMObjectNodes always in memory, which seems acceptable to me (I would
not even dare to estimate how much is in memory in the _current_
implementation)
Inheritance could make this number considerably larger though. If for
example vpro (having about 200 builders) would like to define object
-> object (related) then it would cost them 200 * 200 = 40000
MMObjectNodes in this cache. Still affordable, but I'd say they simply
should not do such a thing, and in practice it should become only
little bigger than 676.
I estimate that this implementation would perform about the same as
the original one, though it is not yet really tweaked for
performance. It is garanteed that no database actions occur (until
someone updates, deletes or adds a typerel node).
Reason
========================================
I'd like to add this code to the 1.6 branch (and also 1.7), because
inheritance is part of 1.6, so every change to make it work better is
welcome. The media-project, which heavily uses mmbase-inheritance will
profit, and can easily remain to be 1.6 compatibable.
It is little more than a bugfix so I ask for a Vote, but more
importantly, someone to test/review it.
Remarks ========================================
- Code which looks in the typerel table itself, like the jsp-editors,
will still fail to list all possible relations.
- Perhaps also in BasicNodeManager.getAllowedRelations must change
something to get it right complete there too (i see something with
thisOType there)
- The getAllowedRelation functions of TypeRel return Enumeration. In
1.7 it would perhaps be a nice idea to let them return SortedSets or
Lists in stead.
- Perhaps also must be thought of a way to request the allowed
relations with inheritance partially switch off. if
e.g. object->object (related) is allowed, then in editors you
perhaps only want to see all related 'objects'. and not
differentiated to every object type too. It would perhaps be easy
to implement, because the typerels in the resulting list which are
'automaticly' added because of inheritance are instanceof
VirtualTypeRelNode, while the 'real' ones are not. So perhaps a
function isVirtual() on RelationManager, or something like that?
- perhaps the Set of all TypeRels can be made more efficient by adding also
VirtualTypeRelNodes for the relation destination->source (if dir = 2)?
START OF CALL: Sunday 16 february 2003
END OF CALL: Wednesday 19 february 2003
-- Pierre van Rooden Mediapark, C 107 tel. +31 (0)35 6772815 "Never summon anything bigger than your head."
