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

Hierarchy model inheritance breaks usage with STI and superclass validations #392

Open
bb opened this issue Dec 8, 2021 · 1 comment
Open
Assignees

Comments

@bb
Copy link

bb commented Dec 8, 2021

I was not able to rebuild! the hierarchy in my project after upgrading from 7.3 to 7.4 and found out this is due to the changes of #384.

My models look roughly like this:

class BasicItem < ApplicationRecord
  belongs_to :tenant
end

class HierarchicalItem < BasicItem
  belongs_to :parent, optional: true
  has_closure_tree order: "sort_order", numeric_order: true
end

class SpecificItemA < HierarchicalItem
end
class SpecificItemB < HierarchicalItem
end

In version 7.3 the HierarchicalItemHierarchy(ancestor_id: integer, descendant_id: integer, generations: integer) was extending AR::Base but now in 7.4 it's extending BasicItem which leads to the following issues:

  1. The hierarchy class and table it do not have a tenant_id, it never sets a tenant (and shouldn't), but it's validated to have one when filling the Hierarchy table
  2. it generates invalid SQL when commenting out belongs_to :tenant (as a workaround for 1.) and rebuilding: HierarchicalItemHierarchy Create (5.1ms) INSERT INTO "basic_item_hierarchies" ("ancestor_id", "descendant_id", "generations") VALUES ($1, $2, $3) RETURNING "id" [["ancestor_id", 5653], ["descendant_id", 5653], ["generations", 0]] -- the issue here is "RETURNING ID" because from BasicItem, it infers this would be the primary key while it isn't.

I think #384 should be reverted and another solution should be found for that.

@bb
Copy link
Author

bb commented Jul 4, 2022

#395 seems to be the same issue, so I guess they can be solved together.

@seuros seuros self-assigned this Jul 31, 2022
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

No branches or pull requests

2 participants