-
Type:
Task
-
Status: Done
-
Resolution: Done
-
Affects Version/s: Search Services 1.5, Search Services 2.0
-
Fix Version/s: Search Services 2.0
-
Labels:None
-
Epic Link:
-
Sprint:Team Ninja-King - S&I 28, Team Ninja-King - S&I 29
-
Release Train:Southall
-
Delivery Team:Search
-
Story Points:8
Primitive fields and field types currently defined in the schema should be analysed/revisited in order to
- make clear their purpose and the scenario where they are involved in
- make sure (field types only) they are using the most appropriate Solr type according with that purpose (e.g.
Trie types have been deprecated in favour of Point fields) - make sure the options/flags set on each field/field type provides the best configuration according with its purpose (e.g. indexed/stored/docValues)
Potential expected benefits we are looking for as consequence of that refactor:
- disk space usage (e.g. if a field is single valued and it is docValues enabled, we could avoid to store it)
- better memory usage (e.g. use docValues for sort / facet fields)
At first sight it seems there is some space of improvement. See for example the following field definition:
<dynamicField name="int@sd@*" type="int" stored="true" docValues="true" /> <dynamicField name="long@sd@*" type="long" stored="true" docValues="true" /> <dynamicField name="float@sd@*" type="float" stored="true" docValues="true" /> <dynamicField name="double@sd@*" type="double" stored="true" docValues="true" /> <dynamicField name="date@sd@*" type="date" stored="true" docValues="true" /> <dynamicField name="datetime@sd@*" type="date" stored="true" docValues="true" /> <dynamicField name="boolean@sd@*" type="identifier" stored="true" docValues="true" /> <dynamicField name="category@sd@*" type="identifier" stored="true" docValues="true" /> <dynamicField name="noderef@sd@*" type="identifier" stored="true" docValues="true" />
where as you can see both stored and docValues options have been enabled on single valued fields.
Acceptance Criteria
- This doesn't include fields (mainly text fields) already managed in
SEARCH-2068 - There are useful comments in the schema about the usage and the purpose of each field/field type
- Primitive Fields / field types are properly configured according with their purpose/usage
- No regression