-
Notifications
You must be signed in to change notification settings - Fork 17
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
Fix surrogate PK ordering #681
Conversation
When performing LQ on a table without PKs, we need to ensure that the surrogate PKs that we use (the string representation of the entire row) is properly ordered. Otherwise we will end up with some objects being wrongly categorised as singletons as opposed to being grouped together, which will lead to wrong query results.
If MINIO_CI_CD is not to true Minio container just exits with "Error: Disk `/tmp` is part of root disk, will not be used" and all related tests fail. In addition change the deprecated cred env var names.
@@ -166,7 +169,7 @@ def checkout(self, force: bool = False, layered: bool = False) -> None: | |||
self.object_engine.delete_table(target_schema, table) | |||
|
|||
if layered: | |||
self.lq_checkout() | |||
self.lq_checkout(ddn_layout=ddn_layout) |
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.
Since we've split the read and write shim schemas there's no use in having different overlay layout between cli (_sgov_lower_my_table
foreign table, my_table
view, _sgov_upper_my_table
helper table) and ddn (my_table
foreign table, _sgov_merged_my_table
view, _sgov_upper_my_table
helper table) now in theory.
Even if we decide to try and re-use those schemas to serve up some reads from them, we would need to keep track of the dirty
tables. Since the target table is a dirty table (changed after executing the write), we would need to re-mount a clean shim schema anyway.
When performing LQ on a table without PKs, we need to ensure that the surrogate PKs that we use
(the string representation of the entire row) is properly ordered. Otherwise we will end up with some
objects being wrongly categorised as singletons as opposed to being grouped together, which will
lead to wrong query results.