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

Usage with STI table #438

Open
mbajur opened this issue Jul 12, 2024 · 1 comment
Open

Usage with STI table #438

mbajur opened this issue Jul 12, 2024 · 1 comment

Comments

@mbajur
Copy link

mbajur commented Jul 12, 2024

Hey! First of all - big apologies if such issue was already created at some point. I'm having a hard time trying to even google for it as i'm unsure how to form my search query properly for this one. Anyway, i have a objects table and two STI models using it

class Namespace::Object
  has_many :replies, class_name: 'Comment', foreign_key: :in_reply_to_ap_object_id
  has_closure_tree parent_column_name: :in_reply_to_ap_object_id
end

class Article < Namespace::Object
end

class Comment < Namespace::Object
end

So, basically, it's a one big tree structure with objects associated with each other using in_reply_to_ap_object_id (which is a foreign key to either Article or Comment STI model, basically to Namespace::Object model instance. And now, when I'm doing the following:

article = Article.create! # article.id = 4
comment = Comment.create! # comment.id = 213
comment2 = Comment.create!
article.add_child(comment)
comment.add_child(comment2)

a following record in hierarchies model is being created:

image

The problem is - for some reason unknown to me, the ancestor_id is set to the comment id instead of the article id (213 instead of 4) which leads to me not being able to fetch article comments using hash_tree method. I tried several ways of doing that but each has it's own quirks:

  1. article.hash_tree - this produces SELECT "activity_pub_objects".* FROM "activity_pub_objects" INNER JOIN "activity_pub_object_hierarchies" ON "activity_pub_objects"."id" = "activity_pub_object_hierarchies"."descendant_id" WHERE "activity_pub_object_hierarchies"."ancestor_id" = $1 ORDER BY "activity_pub_object_hierarchies".generations ASC [["ancestor_id", 4]] query which obviously returns nothing as ancestor_id in DB is 213 not 4
  2. article.replies.hash_tree - this returns only 0 generation of records, so just comment is being returned in the hash result. No comment2 as comment child.
  3. article.children.hash_tree - nothing is returned, same query as in 1

I have a gut feeling it's related to the fact I'm using STI instead of having two separate models but that's a requirement of this specific app and i can't really change it.

PS. i just tested deep-nesting several comments and hash_tree works perfectly fine starting from zero level comment - so for my example comment.hash_tree returns a full comments tree as intented. It seems just using article as a source of hash_tree is breaking things

I would really appreciate any tips on this one! 🙏

@mbajur
Copy link
Author

mbajur commented Jul 14, 2024

Alright, it can be easily reproductable using the folowing steps and i think that's a bug:

  1. Define models as mentioned in original post
  2. Try assigning a comment as a child of an article but using becomes method to make sure they are all the same type (i think that's the part that is broken in the gem because when I'm assigning comment to comment - all works fine):
article = Article.create
comment = Comment.create
article.becomes(Namespace::Object).add_child(comment.becomes(Namespace::Object))

becomes might probably be ignored because it's broken anyway. I just used it to try to remove all the moving parts but it didn't helped, so closure_tree is resolving to the proper STI type internally anyway i guess
3. Observe that parend_id was properly populated but the record for given comment (gen 0) in hierarchies table has an ancestor_id set to comment id instead of article id (so ancestor_id = descendant_id). It can be fixed by manually changing ancestor_id to article id but that's not a real solution obviously.

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

1 participant