using has_ancestry in subclass throws error #87
Comments
|
This was caused by ancestry overwriting base_class. It no longer does that in 2.0, thanks to 4e57f32 |
kbrock
added a commit
to kbrock/ancestry
that referenced
this issue
Mar 5, 2023
active_record defines base_class as the top of an STI tree. ancestry had a similar concept. It was the class where ancestry was defined. Since ancestry originally called it a base_class, there was a conflict and in 4e57f32 it was renamed to ancestry_base_class PRs of note: - stefankroes#86 - stefankroes#87 The ancestry_base_class is used quite often to make sure the proper class is accessed to lookup values. I'm not sure the use case for defining ancestry in the middle of a hierarchy, but it breaks a few things. If you define ancestry in the middle of a tree, the parent classes still implement all of ancestry. If these parent classes are added to the tree then the cache counters and finders will not work properly. I'm dropping this custom concept and using the standard rails concept instead, as I think it should have been done originally.
kbrock
added a commit
to kbrock/ancestry
that referenced
this issue
Mar 5, 2023
active_record defines base_class as the top of an STI tree. ancestry had a similar concept. It was the class where ancestry was defined. Since ancestry originally called it a base_class, there was a conflict and in 4e57f32 it was renamed to ancestry_base_class PRs of note: - stefankroes#86 - stefankroes#87 The ancestry_base_class is used quite often to make sure the proper class is accessed to lookup values. I'm not sure the use case for defining ancestry in the middle of a hierarchy, but it breaks a few things. If you define ancestry in the middle of a tree, the parent classes still implement all of ancestry. If these parent classes are added to the tree then the cache counters and finders will not work properly. I'm dropping this custom concept and using the standard rails concept instead, as I think it should have been done originally.
kbrock
added a commit
to kbrock/ancestry
that referenced
this issue
Mar 5, 2023
active_record defines base_class as the top of an STI tree. ancestry had a similar concept. It was the class where ancestry was defined. Since ancestry originally called it a base_class, there was a conflict and in 4e57f32 it was renamed to ancestry_base_class PRs of note: - stefankroes#86 - stefankroes#87 The ancestry_base_class is used quite often to make sure the proper class is accessed to lookup values. I'm not sure the use case for defining ancestry in the middle of a hierarchy, but it breaks a few things. If you define ancestry in the middle of a tree, the parent classes still implement all of ancestry. If these parent classes are added to the tree then the cache counters and finders will not work properly. I'm dropping this custom concept and using the standard rails concept instead, as I think it should have been done originally.
kbrock
added a commit
to kbrock/ancestry
that referenced
this issue
Mar 5, 2023
active_record defines base_class as the top of an STI tree. ancestry had a similar concept. It was the class where ancestry was defined. Since ancestry originally called it a base_class, there was a conflict and in 4e57f32 it was renamed to ancestry_base_class PRs of note: - stefankroes#86 - stefankroes#87 The ancestry_base_class is used quite often to make sure the proper class is accessed to lookup values. I'm not sure the use case for defining ancestry in the middle of a hierarchy, but it breaks a few things. If you define ancestry in the middle of a tree, the parent classes still implement all of ancestry. If these parent classes are added to the tree then the cache counters and finders will not work properly. I'm dropping this custom concept and using the standard rails concept instead, as I think it should have been done originally.
kbrock
added a commit
to kbrock/ancestry
that referenced
this issue
Mar 5, 2023
active_record defines base_class as the top of an STI tree. ancestry had a similar concept. It was the class where ancestry was defined. Since ancestry originally called it a base_class, there was a conflict and in 4e57f32 it was renamed to ancestry_base_class PRs of note: - stefankroes#86 - stefankroes#87 The ancestry_base_class is used quite often to make sure the proper class is accessed to lookup values. I'm not sure the use case for defining ancestry in the middle of a hierarchy, but it breaks a few things. If you define ancestry in the middle of a tree, the parent classes still implement all of ancestry. If these parent classes are added to the tree then the cache counters and finders will not work properly. I'm dropping this custom concept and using the standard rails concept instead, as I think it should have been done originally.
|
Hello @jtromp Not sure if you have github alerts turned on, and you probably moved on from this application a long time ago. But I am hoping you might remember a little bit about this application from 10+ years ago. Do you remember if you liked how this model turned out? Can you guess if putting I'm trying to understand if this is an important feature to keep, and thought I would make a long shot in reaching out to you. Thanks, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I add "has_ancestry" in a subclass of another class (that inherites from ActiveRecord:Base), an error is thrown in development mode:
Mysql::Error: Table 'AUTHORABLE.groups' doesn't exist: SHOW FIELDS FROM
groupsThe class hierarchy in this case is: ActiveRecord::Base > Authorable > Group
The Group class has "has_ancestry" defined. Is this expected behaviour, or is there a solution? I could not find anything related to this in the documentation.
The text was updated successfully, but these errors were encountered: