Changes
→ServiceResponse and related data structures
A ServiceResponse also records which Service generated it, using that Service's service_id/name as defined in config/umlaut_config/services.yml, and generally retrievable from the ServiceList.
So what do we mean by a 'service type'? The list of all valid service types is defined in the ServiceTypeValue table. Each ServiceTypeValue has a one-word internal identifier token (name), a display_name for user presentation, and optionally a display_name_pluralized (to over-ride standard Rails pluralization). The values in this table are initialized from db/orig_fixed_data/service_type_values.yml when you run rake umlautdb:load_initial_data. We intend the local implementer to be able to create locally defined ServiceTypeValues too, if necessary. ServiceTypeValue uses the acts_as_enumerated plug-in to conveniently allow the developer to refer to an individual ServiceTypeValue by name: ServiceTypeValue[:fulltext] ==> the ServiceTypeValue object with name == 'fulltext'. acts_as_plugin does efficient caching.
So obviously which ServiceTypeValue a given ServiceResponse is intended for needs to be registered somewhere. But you won't find it in ServiceResponse, which might be confusing at first. In fact, there's a somewhat confusingly named three-way join object called ServiceType, which ties together:
* a ServiceResponse
* a ServiceTypeValue
* a Request
This architecture theoretically allows:* One ServiceResponse to belong to multiple Requests (ServiceResponse cacheing accross requests/sessions). * One ServiceResponse to be assigned ''multiple'' ServiceTypeValues and thus listed multiple times with a given Request. In fact, Umlaut does not currently use ServiceResponse caching across requests; it turned out to be This data structure is somewhat confusing, but there are usually convenience methods defined to avoid the complexity; they should be used. See for example (tbd).
===Obligations of Service logic===
