You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
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.
The text was updated successfully, but these errors were encountered:
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:
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:tenant_id
, it never sets a tenant (and shouldn't), but it's validated to have one when filling the Hierarchy tableHierarchicalItemHierarchy 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.
The text was updated successfully, but these errors were encountered: