Last modified: 2007-10-12 19:43:06 UTC
For historical reasons SMWTypeHandler->processValue() (and processXSDValue) does
a lot of work and is a "choke point" for working with attribute values.
This affects performance. I verified that a simple inline query like
[[Climate:=+]][[Climate:=*] makes a GetSpecialPropertyValues database query for
SERVICE_LINK, because newAttributeValue() winds up calling the datatype's
processValue() which calls addsServiceLinks whether or not they're needed.
SMWDataValue->setUserValue() and SMWDataType->processValue() need to be
refactored so they do a minimum of work. Just enough to call back to the
datavalue with setProcessedValues() (and possibly even a subset of those values).
Clients who want additional information from a datavalue like $others
(additional conversions built up by setPrintoutString()) quicksearchLink, and
serviceLinks should explicitly ask for them from the datavalue, which asks its
datatype for them. As part of this refactoring, there could be a base class for
all datatypes providing a default implementation, which would reduce code size.
This should be fixed now, since all datatype handlers have been replaced by much more lazy datavalue implementations.