Skip to content
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

[datatype] fix equals method for udt datatypes across schema upgrades #531

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jhgg
Copy link

@jhgg jhgg commented May 26, 2022

We encountered a bug with this driver, where an altered UDT would cause cass_statement_bind_user_type_by_name_n to fail on a prepared statement that was prepared prior to the db altered.

I think that this should be a sensible fix, it for sure fixes our issue... however, I have no idea if this is actually sound!

Unfortunately I do not have a C++ reproducer for this bug, since we use the rust wrapper to this driver, that reproducer is here: https://gist.github.com/jhgg/d009d1fb994a0fd550bd01bb803baee5

@jhgg
Copy link
Author

jhgg commented May 27, 2022

Thinking about this more, I think that although this is semantically correct for IsValidDataType, it may not be right for equals - so maybe we might introduce a separate method that just does the check of mutual fields and have is valid data type invoke that instead.

Copy link
Contributor

@mpenick mpenick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR.

// newer 'version' of the UDT data type after a schema change event should be
// treated as equivalent in this scenario, by simply looking at the first N
// mutual fields they should share.
size_t min_fields_size = std::min(fields_.size(), user_type->fields_.size());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems reasonable to me. It does seem that after creating a type that a type can only be altered in the following ways:

  • Rename field: ALTER TYPE address RENAME zip TO zipcode AND street_name TO street
  • Add a field: ALTER TYPE address ADD country text

It'd be nice to have some tests that verify this is a correct assumption.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be nice to have some tests that verify this is a correct assumption.

I'm not entirely sure how we would test that? Are you suggesting we try to test that the database rejects invalid DDL?

There is a third way, you can change the type of a field ALTER field_name TYPE new_cql_datatype - however, I think if you're doing this, you probably need to redeploy your application anyways since the types are changing.

@jhgg
Copy link
Author

jhgg commented May 27, 2022

Thanks for the PR.

What do you think about my second comment? Should I instead refactor this into a "is valid data type for" method, that way equals still remains an equality check?

Additionally, if that's the case, we can drop the name check on the field, this will allow us to handle renaming of a field, and still considering them equal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants