Conversation
6b78318 to
5d5a089
Compare
| } | ||
|
|
||
| // TODO: I think this might need to be changed, we should only support search on the search endpoint | ||
| if options.filter.None() || !options.filter.IsIndexed() { |
There was a problem hiding this comment.
Do we still support search as a reader option or should it only be part of the search API?
There was a problem hiding this comment.
The reader option is internal to us but to answer your question, yes we need to support it till we backfill the secondary indexes and point the read queries to start using secondary indexes. Then it will only be Search.
5d5a089 to
7a925db
Compare
7a925db to
d7051f1
Compare
| SecondaryIndex: SecondaryIndexConfig{ | ||
| ReadEnabled: false, | ||
| WriteEnabled: false, | ||
| ReadEnabled: true, |
There was a problem hiding this comment.
let's not enable it in the config yet.
| } | ||
|
|
||
| // TODO: I think this might need to be changed, we should only support search on the search endpoint | ||
| if options.filter.None() || !options.filter.IsIndexed() { |
There was a problem hiding this comment.
The reader option is internal to us but to answer your question, yes we need to support it till we backfill the secondary indexes and point the read queries to start using secondary indexes. Then it will only be Search.
| eqPlan, err := eqKeyBuilder.Build(queryFilters, coll.QueryableFields) | ||
| if err == nil { | ||
| for _, plan := range eqPlan { | ||
| if indexedDataType(plan) { |
There was a problem hiding this comment.
if it is equality and the plan is not index type what is the behavior?
There was a problem hiding this comment.
This can happen if the field is a []byte. Then the plan is ignored and we look for another eq plan or move to range plans
| if len(repeatedFields) == 0 { | ||
| // nothing found or a gap | ||
| return nil, errors.InvalidArgument("filters doesn't contains primary key fields") | ||
| if s.matchAll { |
There was a problem hiding this comment.
So this will go away once we move to secondary indexes because then it doesn't matter if we are able to build the primary key from the filter.
There was a problem hiding this comment.
Yes that will be awesome. I've created #870 to remember to do this.
| } | ||
|
|
||
| // Prefer a RANGE scan which should read back less keys than a FULLRANGE | ||
| // for _, queryType := range []filter.QueryPlanType{filter.RANGE, filter.FULLRANGE} { |
| // Range Key Composer will generate a range key set on the user defined keys | ||
| // It will set the KeyQuery to `FullRange` if the start or end key is not defined in the query | ||
| // if there is a defined start and end key for a range then `Range` is set. | ||
| type RangeKeyComposer[F fieldable] struct { |
There was a problem hiding this comment.
For this diff, the structure is good. But if we think about it, we just need two high level abstractions here,
NewQueryableKeyBuilder(composer, primaryKey)[will be used by insert/replace only]NewQueryableKeyBuilder(): This will internally use eq/range composer to build plans i.e. equality as well as range. The reason being once we don't rely on the search store then either the plan is formed or we need to fall back to full table scan, there will be no other option. ThenRead/Update/Deletecan rely directly on it. This means we need to add something to the QueryPlan so that caller knows whether the keys are for primary or secondary indexes.
There was a problem hiding this comment.
Yes I like it. We can definitely move to that direction once search and secondary are ready.
garrensmith
left a comment
There was a problem hiding this comment.
Thanks for the feedback. I've made the changes.
| } | ||
|
|
||
| // NewPrimaryKeyEQBuild returns a KeyBuilder for use with schema.Field to build a primary key query plan. | ||
| func NewPrimaryKeyEqBuilder(keyEncodingFunc KeyEncodingFunc) *KeyBuilder[*schema.Field] { |
There was a problem hiding this comment.
I think we could do that a little later once secondary indexes are deployed. At the moment we have to pass some extra params if it is a PrimaryKey versus secondary.
| if len(repeatedFields) == 0 { | ||
| // nothing found or a gap | ||
| return nil, errors.InvalidArgument("filters doesn't contains primary key fields") | ||
| if s.matchAll { |
There was a problem hiding this comment.
Yes that will be awesome. I've created #870 to remember to do this.
| // Range Key Composer will generate a range key set on the user defined keys | ||
| // It will set the KeyQuery to `FullRange` if the start or end key is not defined in the query | ||
| // if there is a defined start and end key for a range then `Range` is set. | ||
| type RangeKeyComposer[F fieldable] struct { |
There was a problem hiding this comment.
Yes I like it. We can definitely move to that direction once search and secondary are ready.
| eqPlan, err := eqKeyBuilder.Build(queryFilters, coll.QueryableFields) | ||
| if err == nil { | ||
| for _, plan := range eqPlan { | ||
| if indexedDataType(plan) { |
There was a problem hiding this comment.
This can happen if the field is a []byte. Then the plan is ignored and we look for another eq plan or move to range plans
0eb65ee to
2726177
Compare
| } | ||
| collation = value.NewCollationFrom(apiCollation) | ||
|
|
||
| if buildForSecondaryIndex && collation.IsCaseInsensitive() { |
There was a problem hiding this comment.
So we won't be supporting case-insensitive queries on secondary indexes fields?
There was a problem hiding this comment.
We can support it in the in-memory filter part but not part of what we use to build the range keys. Or at least I can't think of a way of making that work.
There was a problem hiding this comment.
Sure, we can figure it out iteratively.
0896d17 to
74869e7
Compare
Supports $eq, $lt, $lte, $gt and $gte queries from the secondary index. The secondary index can be used for reads, updates and deletes.
74869e7 to
76374a1
Compare
|
🎉 This PR is included in version 1.0.0-beta.46 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Describe your changes
Secondary Index reader that queries from the secondary index.
How best to test these changes
Issue ticket number and link