The databases allow you to dynamically set up view query clauses (view or treeview) in a dynamic way, which will be combined with the view query (by and).
They can be used to process the compartmentalization of data sources, depending on the context of the request (the connected user in particular, but also the schedule for example).
Bases are instances of PreparedWhere to set as query attribute.

Standard attributes

To determine the bases; at each query execution, we start by looking at whether there is a query attribute called init_base_rest_<name of the view> type wsnoheto. engine. PreparedWhere. If it exists, we use this one. Otherwise, we look for one called init_base_rest. If so, then we use it.
Then, we add all the found databases that are listed for the view in its configuration.

Bases in view configuration

The base property allows you to specify a table of bases that will be used for each query with this view, in addition to the standard attributes.
For example:

{
  "objectname": "asset",
  "description": "description",
  "query": "",
  "bases": [ "StatusOnLine", "NotExpired" ],
  "orderby":"pid",
  "secured":true,
  "max":0,
  "from":0,
  "fulltext":"",
  "props": [ "id", "name", "status.id", "status.name" ],
  "aggs": {
    "fieldname1": {
      "props":["id", "name", "status.id"]
    }
  }
}

JSP

The JSP to use to generate the databases is /bov3/common/init/init_base_rest.jsp up to and including 11.9. As of 11.9.1 and after, the URL is /_restapi/init/init/init_base_rest.jsp.

Prepared where service

11.25

Prepared where services (ie com.noheto.preparedwhere.PreparedWhereService) can be referenced in dam and data API since 11.25.

The principle is a mapping between the API context and the Prepared Where Service context system. Each service Each service has its own context and it is possible to indicate which context of Prepared Where Services to use for it.

The mapping can be configured in the API Admin (Base wheres mapping icon):

Simplified syntax

The configuration consists of a json that defines which Prepared Where Service context should be used for a given API service context, in the form of associations API context = PWS context (or list of PWS contexts).

API Contexts

Here is the list of API contexts (ie the key in mappings):

$default : the mapped values are the contexts used if no mapping is found for a given API context
search: API context for search (topsearch, infinite lists…)
list: API context for paginated list
tree: API context for tree
read: API context for get with an id
update: API context for retrieving data after creation or modification (or collection item assignment)
aggs: API context for “aggs” service
$all: this key allows setting a mapping for all API context (the mapped values will be added to values mapped to the key, or to $default, if no specific mapping is found for the API context ).
massimport_out
massimport_in
list_children: API context for metadata children queries (with configurable fallback (see https://crossmedia.atlassian.net/wiki/spaces/WD/pages/11764307/Appendix1+Configuration#applyDependencyBaseWheres ))
list_agg: API context for aggregates queries (with configurable fallback (see https://crossmedia.atlassian.net/wiki/spaces/WD/pages/11764307 ))

Full syntax

For each association, you can set:

a single value, that is the PWS to map
The PWS base_search_list is mapped to API search context (that means, when a search is done, the base where from base_search_list is used)
{ "search": "base_search_list" }
a list of values, that are the different mappings used
That means, when a search is done, the base wheres from base_search_list and base_list are used.

{ "search": ["base_search_list","base_list"] }
an object, that allow to define different mappings depending of object
$default defines the mapping for unmapped keys:

In the example above, all API contexts are mapped to mapping_default, except for infinite list or topsearch, which are mapped to mapping_search, except for the asset object, which is mapped to mapping_search_asset.
a null value means no context (so no base where from Prepared Where Services)

Defaults

Business Service

11.14

It is possible to manage bases by Java code. To do this, simply create a plugin and copy the jar restapibs.jar () into its lib folder. Then make a class that extends com.noheto.restapi.APIBaseWhereBusinessServiceAdapter.

The principle is to code a method that returns a PreparedWhere (or null for any base) that will be combined by and with the main query, according to a call context (a service, a configuration, a requested object, a user, etc).

method `PreparedWhere getPreparedWhere(Context context)`

Overrides this method to provide a base where.

method `PreparedWhere getPreparedWhere(Context context, String id)`

Overrides this method to provide the base where corresponding to a specific standard id (see Bases in view configuration).

Argument context

This argument provides access to the call context.

getRequest

Returns the http servlet request instance.

getSurfer

Returns the surfer.

getLocale

Returns the locale of the query (could be different than the surfer locale).

getServiceId

Returns the service id. Refer to the com.noheto.restapi.ServiceId class for identifiers.

getConfigId

Returns the configuration id.

getObjectName

Returns the name of the object (object type).

getMethod

Returns the real method (do not use getMethod() of HTtpServletRequest for this).

Example

Dependancy and agregates base wheres

From 2022.4, two types of extensions are provided:

DependencyBaseWhereBusinessServiceAdapter
to provides base where for the metadata children queries
AggBaseWhereBusinessServiceAdapter
to provides base where for the agregate queries