I decided to take another, deeper look at the
get(Enitiy/Map/..)asList/asMap methods that have recently surfaced as
performance and maintainance problems (e.g. for the self-maintaining
DataMap). Basically I think the situation can be fixed with a couple of
small, clean cuts that have no or limited impact now, but pave the way for
easier maintainance later.
Mostly I think that by simply deleting some methods we'll solve a lot of
problems - see below for a somewhat ordered list of steps to take.
Generally I think that methods should well be allowed to return direct
collection references (documented to be read-through and unmodifiable to
prevent corruption); if a client needs to modify internal structures while
iterating over them (Modeler, regression app) the penalty for creating the
new collection should be there, not in the framework where most penalties
currently reside.
I have almost three days that I can burn on this and am reasonably sure I
can finish most, if not all points without causing regressions, so that we
can see about wrapping up beta1. Alternatively I can put these on the list
for beta-2, so that we can boast about the performance improvements. ;-)
Everybody please let me know ASAP how you think about these (today if
possible). Same for the new Configuration; I'd like to get this out of my
tree so that I can work with small change sets. Of course I can just as
well do a BingBang(tm) integration but that will only cause much gnashing
of teeth..
Holger
--snip--
List of action points:
DataContext.getDataMapsAsList:
- could be renamed to getDataMaps (original name actually)
- just returns getDataMapsAsList from its parent (DataDomain, see next
item); IMHO a good idea to change both to return an immutable
write-through Collection reference. This better decouples the QueryEngine
method from the internal implementation (no implementation details in
interfaces!)
DataDomain.getDataMapsAsList/getDataNodesAsList:
- probably should be renamed getDataMaps/getDataNodes and return immutable
read-through Collection references
- clients would have to make a copy themselves (NOT required for 99%!)
- not too many changes except for fixing get(0) in tests to use iterator
- returning immutable List would mean we have to maintain a cached List
somehwere
-> Collection better (as neutral as possible, see above)
DataNode.get/setDataMapsAsList:
- rename to getDataMaps
- return immutable read-through Collection reference from EntityResolver
- setter takes any Collection and copies references; no other changes
necessary
EntityResolver.getDataMapsList:
- rename to getDataMaps
- return immutable read-through Collection
DataMap:
- rename to getDb/ObjEntities
- return immutable read-through Collection
- remove getDbEntityMap (not used elsewhere)
-or-
- remove *List methods completely
- rename getDb/ObjEntityMap to getDb/ObjEntities
- return immutable read-through Map
Entity:
- get(Attribute|Relationship)(Map|List): either/or, just like with DataMap
DataContext:
- instead of calling clearFlattenedUpdateQueries from ContextCommit make
DC clean up itself after commit; make method private or remove completely
ObjRelationship:
- rename getDbRelationshipList to getDbRelationships
- return immutable List
- cache reverseRelationship
DbRelationship:
- cache reverseRelationship
This archive was generated by hypermail 2.0.0 : Thu Mar 13 2003 - 12:21:03 EST