Issue

Today we use collection/index field names to define filter queries as:

const logicalFilter: LogicalFilter<Student> = {
			op: LogicalOperator.AND,
			selectorFilters: [
				{
					op: SelectorFilterOperator.GTE,
					fields: {
						"address.zipcode": 1200,
					},
				},
				{
					op: SelectorFilterOperator.LTE,
					fields: {
						balance: 1000,
					},
				},
			],
		};

where field names address.zipcode and balance are plain strings/object keys and not tied to schema. If a user renames/removes any of these fields, the filters would break and user would have to do a static search across the codebase to find potential usages.

Other than filters, there are places where collection/index field names are being referenced:

• In SearchQuery
• In FindQuery
• and UpdateQuery

What needs to be done?

• Potentially we can make all these generics and tie them to the collection class or interface type. We had a solution that was reverted in the past and covered most of the use cases except a couple ones:

1. It would be great if it can support dot notation for writing nested fields like - address.zipcode
2. The optional fields in collection/index schema were not getting typed. E.g. - if your collection schema defined id: string and an optional employeeName?: string property, the type checking was only available for id and not employeeName

Otherwise, we were getting type safety and auto completion in IDE with above.