/**
* Populates the list with all entity objects for the
* Search Service given any one of the entity objects used.
* @param searchServiceId. the search service identifier
* @param obj. The entity object from which all other are
* retrieved
* @return the list of all entity objects for the this search
* service given a specified object parameter.
*/
List getObjectList(final SearchServiceKey serviceId,
final Object obj) throws AppException,
InformationalException;
As mentioned earlier, it is possible for data in a Search Service to be gathered from a number of different entities. It is also possible for these entities to be related by complex foreign key relationships (for example, an Address record could be related to a Person record via an addressID which is linked via a concernRoleAddressID which is in turn linked via a concernRoleID).
Things are made more complex when one of these entities gets updated via the application. When this happens, the Generic Search Server must be able to work out which entity has just been affected, what Searches it is involved in, and how it is related to every other entity included in each Search Service.
Ultimately, one or more Documents on one or more Search Service Indices will need to be updated, and information in these Documents may be gathered from a range of entities, not just the one that just got modified. However, given that Search Services have one and only one Mapper, each Mapper implementation only needs to worry about assembling information for its own Search Service.
The getObjectList interface method addresses this problem. Given a single updated entity record, getObjectList assembles all other entity Dtls records which will be required to update the corresponding Document in the current Search Service Index. The getObjectList method needs to be coded in such a way that any of the entities involved in a Search Service can be used as the starting point of this process. getObjectList is responsible for:
The mapper.getobjectList () method is called in the following processes:
Note that for initial Database Extraction, the getObjectList interface method gets invoked for every item fetched from the ReadmultiOperation; typically this will be the top-level entity in this case (for example, for a Person Search Extract, all Person records would be read in a readmulti; getObjectList will then be called for each to retrieve all of the other information required to build a SearchServiceRow).
If this method is called for an input that isn't relevant to this search service, then the implementation should simply return an empty list.