Virtual Lookups: General implementation
Lookups in GG are mappings of entity primary keys to their respective labels or names: for example accession_lookup
provides a mapping of accession_id
to accessionNumber
.
This issue is part of #282 (closed).
Selecting what to update
The Curator Tool uses the standard getData()
SOAP endpoint and it provides the following parameters when fetching data for *_lookup
dataviews:
/**
* Lookup parameters
*/
static class LookupFilter {
/**
* Minimum createdDate
*/
public Date createdDate;
/**
* Minimum modifiedDate
*/
public Date modifiedDate;
/**
* Set of valueMember to search for.
*/
public Set<String> valueMember;
/**
* Minimum PK inclusive
*/
public Long startPKey;
/**
* Minimum PK exclusive
*/
public Long stopPKey;
// /**
// * Set of displayMember
// */
// public Set<String> displayMember; // Appears not to be used in any GG *_lookup dataview SQL queries
}
As mentioned above, valueMember
maps to the table's primary key in 99% of all cases.
The first task is create a JPA query that will fetch the target entity for these specific filters. The predicate must use OR and it must only specify the clauses for which values are specified. The SQL example below shows how OR is applied:
WHERE
((sdf.created_date > COALESCE(:createddate, '1753-01-01'))
OR (sdf.modified_date > COALESCE(:modifieddate, '1753-01-01'))
OR (sdf.sys_dataview_field_id IN (:valuemember))
OR (sdf.sys_dataview_field_id BETWEEN :startpkey AND :stoppkey))
After we fetch the matching entities we can generate the response.
Generating a response
For entities that match the specified lookup parameters, we need to identify the field that has @LookupValue
annotation (if missing, use field with @Id
annotation) to use as value member.
Question: Can we add @LookupDisplay
annotation to a method? That way we can somewhat customize the String that is returned.
Since getData()
is used, we must return a Datatable
with at least two columns: value_member
and display_member
.