-
Notifications
You must be signed in to change notification settings - Fork 154
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
In-Memory Server #116
In-Memory Server #116
Conversation
Pull Request Test Coverage Report for Build 921917853
💛 - Coveralls |
7ab7452
to
d522b8f
Compare
beee0ed
to
08498f8
Compare
This Implementation
The Real McCoy
I'll take being ~42seconds slower than the original on an unoptimised implementation 🎉 |
I was upset at the performance so I added the indexes to the cache and now it flies! |
not found yet, but I think when I changed |
The cache locking was (probably) a red herring 🐟 however I still have my doubts. Either way: real ovsdb this impl |
|
||
// interfaceToSetMapOrUUIDInterface takes a reflect.Value and converts it to | ||
// the correct OVSDB Notation (Set, Map, UUID) using reflection | ||
func interfaceToOVSDBNotationInterface(v reflect.Value) (interface{}, 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.
I wonder if we could somehow pick up the ColumnSchema the Mutation / Condition applies to and use bindings.go::OvsToNative
et.al. I think it would be more reliable.
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.
I initially thought about this but:
- I couldn't figure out how to get the ColumnSchema to be available when marshalling to a struct from JSON
- The alternative to ☝️ was to indirect access to the
value
usingValue(schema *ColumnSchema)
which would convert it, but I disregarded that but because you could use the wrong ColumnSchema AND you had to useNewCondition/Mutation
directly and couldn't quickly create instances of the struct.
The other big issue with OvsToNative
apart from needing the ColumnSchema was that it assumes sensible types, and doesn't support the "interesting" types we get from the back from the JSON Parser. E.g []interface{}{"set", []interface{}{[]interface{}{"named-uuid", "foo"}, []interface{}{"named-uuid", "bar"}}}
Ultimately we'd need to fold this code in to OvsToNative anyway so it's probably ok where it is for now.
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.
I agree OvsToNative
is cannot deal with the different kind of types per column but using the *ColumnSchema will save many problems. If there is any type mismatch it will be picked early on.
Only reviewed the first half, but posting some comments early on |
This allows for a Condition to be evaluated based on two supplied values. Signed-off-by: Dave Tucker <[email protected]>
The unmarshal methods didn't use pointer receivers Go case statements don't fallthrough While scalar values are easily type asserted when marshalled to an interface{} the same is not true for map, set and uuid types. We need to use reflect to determine the OVSDB type before storing as an interface{} value. Signed-off-by: Dave Tucker <[email protected]>
This was incorrectly disallowing mutations where a single string would be inserted in to a []string... or int, real etc... Signed-off-by: Dave Tucker <[email protected]>
Signed-off-by: Dave Tucker <[email protected]>
Signed-off-by: Dave Tucker <[email protected]>
And rename Set to Create. This allows for a caller to Add/Update/Delete cached rows with the appropriate locking. Signed-off-by: Dave Tucker <[email protected]>
To make this work, we add NamedUUID detection. A named UUID is considered a default value as it's yet to have been processed by the server. Signed-off-by: Dave Tucker <[email protected]>
This adds an initial in-memory server implementation. It implements enough of the spec to be used for testing. Signed-off-by: Dave Tucker <[email protected]>
This commit make a few changes to the cache. 1. Deprecates the TableCache.Set API, instead only allowing data to be provided in a call to NewTableCache 2. Disallow RowCache creation via API and instead init the cache based on the contents of the provided schema. This removes having calling code check for table existence 3. Rename Row.Set to Row.Create and provide an additionally check the type of the provided Model matches the schema 4. Cache row indexes for increased lookup speed Signed-off-by: Dave Tucker <[email protected]>
Since the TableCache already does this, we don't need to implement checks. Just check for errors on cache operations Signed-off-by: Dave Tucker <[email protected]>
Signed-off-by: Dave Tucker <[email protected]>
1. Rename ninserts to inserts 2. Adds support for multiple clients in series/parallel 3. Ensures that we wait for the event to be received in cache Signed-off-by: Dave Tucker <[email protected]>
This ensures minimal delay between sending a transact response and the update notification being sent via monitor Signed-off-by: Dave Tucker <[email protected]>
This removes the lock on TableCache and instead achieves the same result by locking all of the RowCaches. This is possible because the map in the TableCache doesn't change after creation, only the contents of the RowCache. Signed-off-by: Dave Tucker <[email protected]>
Signed-off-by: Dave Tucker <[email protected]>
Ok I didn't break it, GitHub did: https://www.githubstatus.com/ |
Signed-off-by: Dave Tucker <[email protected]>
@amorenoz I think that's most of the comments addressed. I've opened 2 issues to track the other comments so they don't get lost. This is getting pretty big so I'd like to get it merged then we can start fixing issues in the |
Agree. LGTM |
Closes: #130