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.
