[SERVER-29163] Version match expressions Created: 12/May/17  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: David Storch Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-29590 Version the Matcher Closed
is duplicated by SERVER-29591 Allow users to set a $version field i... Closed
Related
is related to SERVER-1475 {field: {$type:"array"}} should retur... Closed
Assigned Teams:
Query Optimization
Participants:

 Description   

Match expressions are now stored persistently in the catalog as part of the document validation and partial index features. Particularly in the case of partial indexes, this can make it difficult to safely change the semantics of the match language (which we will inevitably want to do from time to time).

As an example, suppose we have some match expression M which matches document x. A user creates a partial index whose partialFilterExpression contains M, resulting in a single index key for document x. In a future version, we change the semantics of M so that it matches both x and y. On upgrade, the index becomes broken in that it contains no index key for y. Queries using the index will incorrectly miss y because of this the absence of this key.

In order to avoid such situations, we should introduce a notion of versioning in the match language. Persisting this version on disk would allow us to know which set of matching semantics to apply to collections or indexes created on older versions. We could allow users to specify the version they wish to use while querying, which would allow us to avoid breaking legacy applications. Breaking changes would be more friendly if we can document old match expression versions as deprecated and then remove support after some grace period. Right now, such changes require all applications to adjust immediately as part of upgrade.



 Comments   
Comment by Kyle Suarez [ 07/Sep/17 ]

Acknowledged; thanks!

Comment by David Storch [ 06/Sep/17 ]

nicholas.zolnierz kyle.suarez, I'm removing this from the JSON Schema project, as it doesn't look like we'll have time to do it, and it's not required.

Comment by David Storch [ 28/Aug/17 ]

Let's take a sweep through the unfinished JSON Schema tickets in about two weeks time to decide what can be cut. But yes, since this isn't required for the project, I'm assuming we'll bump it out of the epic.

Comment by Kyle Suarez [ 28/Aug/17 ]

If this is going to the Backlog, can we remove it from the JSON Schema epic?

Generated at Thu Feb 08 04:20:04 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.