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

Fix migrating between aliased and non-aliased computeds #6566

Merged
merged 1 commit into from
Dec 12, 2023

Conversation

msullivan
Copy link
Member

This version is designed to be cherry-pickable to 4.x, so it doesn't
change how any of our schemas are represented, it just tries to
actually fully make the transition when we switch.

I'm going to do a follow-up where I rip all of this out and the cost
of schema changes.

This version is designed to be cherry-pickable to 4.x, so it doesn't
change how any of our schemas are represented, it just tries to
actually fully make the transition when we switch.

I'm going to do a follow-up where I rip all of this out and the cost
of schema changes.
Comment on lines +1208 to +1210
(cur_base := self.scls.get_bases(schema).objects(schema)[0])
and (subj := cur_base.get_subject(schema))
and subj == self.scls.get_subject(schema)
Copy link
Contributor

Choose a reason for hiding this comment

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

This checks if my subject is also the subject of my first base.

So it checks that I'm haven't been rebased to a different subject?

Why is this here?

Copy link
Member Author

Choose a reason for hiding this comment

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

This is detecting the case discussed in #6568, where an aliased computed is actually the subtype of the other pointer that it is aliasing

@msullivan
Copy link
Member Author

@elprans Could you take a look at this?

@msullivan msullivan merged commit af37905 into master Dec 12, 2023
22 checks passed
@msullivan msullivan deleted the to-computed-error-2 branch December 12, 2023 20:47
aljazerzen pushed a commit that referenced this pull request Dec 15, 2023
This version is designed to be cherry-pickable to 4.x, so it doesn't
change how any of our schemas are represented, it just tries to
actually fully make the transition when we switch.

I'm going to do a follow-up where I rip all of this out and the cost
of schema changes.
msullivan added a commit that referenced this pull request Dec 19, 2023
This version is designed to be cherry-pickable to 4.x, so it doesn't
change how any of our schemas are represented, it just tries to
actually fully make the transition when we switch.

I'm going to do a follow-up where I rip all of this out and the cost
of schema changes.
msullivan added a commit that referenced this pull request Dec 20, 2023
This version is designed to be cherry-pickable to 4.x, so it doesn't
change how any of our schemas are represented, it just tries to
actually fully make the transition when we switch.

I'm going to do a follow-up where I rip all of this out and the cost
of schema changes.
aljazerzen pushed a commit that referenced this pull request Dec 21, 2023
This version is designed to be cherry-pickable to 4.x, so it doesn't
change how any of our schemas are represented, it just tries to
actually fully make the transition when we switch.

I'm going to do a follow-up where I rip all of this out and the cost
of schema changes.
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.

None yet

3 participants