-
-
Notifications
You must be signed in to change notification settings - Fork 211
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
memory: index: various inconsistencies and potential bugs #1613
Comments
In RenameIndex, the function is defined in the interface as:
This implies that the function should return an error if toIndexName already exists, but the implementation in memory/ does not:
|
In |
In the table index, createIndex is passed a list of columns, Is it necessary for the underlying storage driver to store the full expression? Couldn't this be simplified to store just the column names? This is a more unimportant question than the others, more of a performance optimization (skipping parsing the expressions) |
In the table index, the In that same function it checks if the values of those columns have any nulls, and skips the entire row if so. This seems like a mistake: shouldn't the non-nil values be checked for uniqueness rather than skipping the entire row? |
I guess most of this can be chalked up to #1347 - that the in-memory indexes are currently pretty much unimplemented. |
Thanks for using I think you are correct that most of the issues you are seeing with drop and rename index are that the backend implementations are responsible for implementing these behaviors and the in memory index does not. We don't use the raw in memory GMS index implementation in Dolt so we've never prioritized a more robust implementation. This is definitely a place where we'd love a hero open source contribution :-) |
According to the interface definition for IndexAlterableTable:
However the DropIndex in memory/ does not return an error if the index does not exist:
Which should be updated, the interface, or the memory/ impl?
The text was updated successfully, but these errors were encountered: