-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Indexing for model fields #221
Conversation
Signed-off-by: Carson Farmer <[email protected]>
Signed-off-by: Carson Farmer <[email protected]>
Signed-off-by: Carson Farmer <[email protected]>
Signed-off-by: Carson Farmer <[email protected]>
Signed-off-by: Carson Farmer <[email protected]>
Signed-off-by: Carson Farmer <[email protected]>
Signed-off-by: Carson Farmer <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some comments for you guys. Be gentle!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! Heavy lifting.
I can see multiple points of improvement, but with some design changes that not sure may worth it. Also, It seems that we have the right extensibility points at different parts of the code.
Some memory benchs sounds good since some extra fetches of old state might hurt a bit in some cases (delete)... but feels that more for an optimization stage.
I think @sanderpick and you have a more clear need of why this was needed now, so maybe I'm missing a better analysis of the original motivation. I think was the unique index part, not sure about being slow for an existing use-case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice @carsonfarmer 💪 !
Some high-level comments added. @jsign, correct, the immediate use case is to enable something like, give me the user with a given email. So, the primary focus is the unique field bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey gang, just one or two points of clarification and then I'll push two fixes before merging.
Signed-off-by: Carson Farmer <[email protected]>
Signed-off-by: Carson Farmer <[email protected]>
Signed-off-by: Carson Farmer <[email protected]>
Ok, I think all nits etc have been addressed. Ready for merge. |
@@ -96,7 +96,7 @@ func (c *Client) NewStore(ctx context.Context) (string, error) { | |||
} | |||
|
|||
// RegisterSchema registers a new model shecma | |||
func (c *Client) RegisterSchema(ctx context.Context, storeID, name, schema string, indexes []*store.IndexConfig) error { | |||
func (c *Client) RegisterSchema(ctx context.Context, storeID, name, schema string, indexes ...*store.IndexConfig) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Building indexes currently does not affect any other tests, and adds a unique constraint on the ID field by default (so this is partial support for Unique). Any other fields can be specified using arbitrary 'paths' (e.g.,
Book.Title
). Currently only JSON mode is supported. Structs could be added later, but this seems good enough for a POC and early tests. This work stores the indexes 'above' any model key paths in the underlying stores, so as to avoid showing up in queries etc. Finally, it requires an EventCodec to call an IndexFunc within the Reduce method as discussed.Still left to do: