# Join us on Nov 16th for our Community Meeting
**URL:** https://forum.opensearch.org/t/join-us-on-nov-16th-for-our-community-meeting/7566
**Category:** Community
**Tags:** community-meeting
**Created:** [November 10, 2021, 10:32pm UTC](https://forum.opensearch.org/t/join-us-on-nov-16th-for-our-community-meeting/7566 "2021-11-10T22:32:48Z")
**Posts on this page:** 1
**Showing post:** 4
### Author:  [@kris](https://forum.opensearch.org/u/kris)
#### Post date: [November 16, 2021, 10:38pm UTC](https://forum.opensearch.org/t/join-us-on-nov-16th-for-our-community-meeting/7566/4 "2021-11-16T22:38:31Z")
Link to our agenda & chat log: [https://hackmd.io/@searchymcsearchface/H1lPogJJF](https://hackmd.io/@searchymcsearchface/H1lPogJJF)
Slides:
>
>
> \### Problem Statement
>
> By default, OpenSearch supports ‘schema on write’ i.e. …the structure is defined at the time of ingest so that it is available for query immediately. However, as use cases for OpenSearch evolved, there is a need for greater flexibility. End users may not be aware of the data structure or may want additional attributes to query upon post ingest. This is where ‘schema on read’ is useful. With ‘schema on read’, the query result field can be defined at the time of query. This also helps greatly improve ingest rate by avoiding having to index fields that are not always going to be queried right away.
>
> \### Requirements
>
> 1. Ability to define fields that are evaluated at query time.
> 2. No changes should be made to the underlying schema. This avoids the need to re-index existing data.
> 3. These user defined fields should support all operations of a regular field in the query.
>
> \### Existing Solution
>
> \#### Scripting
>
> Scripting is supported at various constructs of the \_search request body. In each of these constructs, the fundamental working is same: script is evaluated at query time, it derives value/s from the indexed field/s and acts on the derived values.
>
> \* In query and filter context, the derived value can be used to filter out documents.
> \* In aggregations, results can be aggregated on the derived value.
> \* The derived values can be exposed as a custom field by including it in script\_fields.
> \* Results can also be sorted on the derived value.
> \* Using script\_score, the derived value can be used to score the filtered documents.
>
> \### Shortcomings of existing solution
>
> Scripting satisfies most of the requirements listed above but adding scripts to the request make it bulky, non-readable and difficult to manage. Even though scripts can be stored and referenced in the query, it does not help the readability.
>
> Following example highlights the same:
> \`\`\`
> GET index\_1/\_search
> {
> "query": {
> "bool": {
> "filter": {
> "script": {
> "script": """
> return ChronoUnit.YEARS.between(doc\['dob'\].value, doc\['create\_time'\].value) \> 18;
> """
> }
> }
> }
> },
> "aggs": {
> "day-aggregations": {
> "histogram": {
> "interval": 10,
> "script": {
> "source": "ChronoUnit.YEARS.between(doc\['dob'\].value, doc\['create\_time'\].value);"
> }
> }
> }
> },
> "sort": {
> "\_script": {
> "type": "number",
> "script": {
> "source": "ChronoUnit.DAYS.between(doc\['dob'\].value, doc\['create\_time'\].value);"
> },
> "order": "desc"
> }
> },
> "\_source": true,
> "script\_fields": {
> "age": {
> "script": "ChronoUnit.YEARS.between(doc\['dob'\].value, doc\['create\_time'\].value);"
> }
> },
> "size": 10
> }
> \`\`\`
> \### Proposed Solution
>
> Regular OpenSearch queries revolve around fields in the schema. With scripting, the query syntax changes a lot.
> In the proposed solution, we aim to achieve ease of using schema on read along with all the benefits of scripting.
> The proposal includes defining fields in mapping which will be evaluated at query time and behave like regular fields.
> [@Poll: Community Meeting Schedule 2022](https://forum.opensearch.org/t/poll-community-meeting-schedule-2022/7652):
>
> We could use your input. In order to cover more topics and additional time zones, we are planning to expand to weekly community meetings in 2022. As we discussed in the ‘[Join us on Nov 16th for our Community Meeting](https://forum.opensearch.org/t/join-us-on-nov-16th-for-our-community-meeting/7566)’, meetings will be in pairs - one week following the current format, the second week will be more of an open office format. The plan will be to alternate between the two most popular times, therefore allowing the widest access across the globe. Please vote on the preferred times: [p…](https://forum.opensearch.org/t/poll-community-meeting-schedule-2022/7652/1)
Thanks again to all who attended - hope to see you again next time.
> **[Upcoming Events](https://opensearch.org/events/)**
>
> OpenSearch is a community-driven, Apache 2.0-licensed open source search and analytics suite that makes it easy to ingest, search, visualize, and analyze data.
---
_[View the full topic](https://forum.opensearch.org/t/join-us-on-nov-16th-for-our-community-meeting/7566)._