-
-
Notifications
You must be signed in to change notification settings - Fork 93
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
Problem with a polymorphic table query #115
Comments
It doesn't work because inferred combine key is def for_questions(questions)
rename(parent_id: :question_id).where(parent_id: questions.pluck(:id), parent_type: "question")
end Lemme know if that works. I should mention that in rom-repository 1.0.0 this will raise an error telling you that the combine key is missing and how you can make it work :) |
That makes sense, and I had something similar at one stage where I did a
Implying that I can't create the ROM::Struct with the unknown key of I'll dig deeper. |
@mrship ah right, this should be a view with a header: view(:for_questions, %i[id question_id ... ]) do |questions|
rename(parent_id: :question_id).where(parent_id: questions.pluck(:id), parent_type: "question")
end |
btw rom-sql deliberately doesn't support polymorphic associations because we do not want to promote features that throw data integrity out the window; however, since folks may have legacy databases, we can easily provide a plugin that you can enable that will setup associations for polymorphic relations by following how it's done in ActiveRecord. |
OK, that helps in that I now do get a snapshot back (see below), however, I then try to map that result set as an entity, using
in Any thoughts on why a mapping wouldn't work with that struct? The successful bit :)
|
@mrship what's your entity class? |
Sorry, I appreciate that it wasn't a particularly good error report re: the mapping; I'll try and isolate it further and provide some more detail. |
My entity class is a
I have a custom type to create the correct snapshot object. I follow a similar pattern for charts (see above) that I pull back in my object graph with a combine_children/many, e.g.
This works really well for the (many) charts, but not for one snapshot. Digging deeper it seems I'm being bitten by activesupport monkeypatching To be honest, I'm deep in the weeds here, so I'm not sure how to deal with this. I can make my snapshot an array (with one element) and it works fine (following the same pattern as for charts) but I'd prefer to keep it as a single relationship if possible. Any thoughts? (Other than killing activesupport with extreme prejudice, which unfortunately isn't an option)
|
What's Types::Snapshot? You should be able to do `Snapshot.optional`. Struct classes implement Type API.
Cheers
Piotr
…On 17 Dec 2016, 1:11 PM +0200, Andy Shipman ***@***.***>, wrote:
My entity class is a Dry::Struct, along the lines of:
class Question < Dry::Struct constructor_type :schema attribute :snapshot, Types::Snapshot.optional attribute :charts, Types::Strict::Array.member(Lighthouse::Chart).default { [] } end
I have a custom type to create the correct snapshot object. I follow a similar pattern for charts (see above) that I pull back in my object graph with a combine_children/many, e.g.
questions .combine_children( many: { charts: charts, }, one: { snapshot: snapshots.for_questions, } )
This works really well for the (many) charts. but not for one snapshot. Digging deeper it seems I'm being bitten by activesupport monkeypatching Object#try (which is included via another gem I'm using). The (snipped) backtrace for the error shows that I end up in ActiveSupport Object#try when calling try from dry-types. Interestingly I don't follow the same dry-struct code path for charts as it seems an Types::Strict::Array.member doesn't run the try method in the same way.
To be honest, I'm deep in the weeds here, so I'm not sure how to deal with this. I can make my snapshot an array (with one element) and it works fine (following the same pattern as for charts) but I'd prefer to keep it as a single relationship if possible.
Any thoughts? (Other than killing activesupport with extreme prejudice, which unfortunately isn't an option)
"/Users/shipmana/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/core_ext/object/try.rb:64:in `try'", "/Users/shipmana/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/dry-types-0.9.3/lib/dry/types/sum.rb:76:in `block in try'", "/Users/shipmana/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/dry-types-0.9.3/lib/dry/types/constrained.rb:44:in `try'", "/Users/shipmana/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/dry-types-0.9.3/lib/dry/types/sum.rb:75:in `try'", "/Users/shipmana/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/dry-types-0.9.3/lib/dry/types/sum.rb:70:in `call'", "/Users/shipmana/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/dry-types-0.9.3/lib/dry/types/hash/schema.rb:75:in `block in coerce'", "/Users/shipmana/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/dry-types-0.9.3/lib/dry/types/hash/schema.rb:88:in `block in resolve'", "/Users/shipmana/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/dry-types-0.9.3/lib/dry/types/hash/schema.rb:86:in `each'", "/Users/shipmana/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/dry-types-0.9.3/lib/dry/types/hash/schema.rb:86:in `resolve'", "/Users/shipmana/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/dry-types-0.9.3/lib/dry/types/hash/schema.rb:73:in `coerce'", "/Users/shipmana/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/dry-types-0.9.3/lib/dry/types/hash/schema.rb:27:in `call'", "/Users/shipmana/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/dry-types-0.9.3/lib/dry/types/constructor.rb:39:in `call'", "/Users/shipmana/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/dry-struct-0.1.1/lib/dry/struct/class_interface.rb:77:in `new'",
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (#115 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAAEKvexczegNLND5lB6eDem3repGe3Nks5rI8NpgaJpZM4LMy5t).
|
Aha! your comment about optional allowed me to progress. I can specify this as:
to get around the issue I have with ActiveSupport. So, thanks for all the help. Let me also say that ROM is awesome. I'm enjoying the freedom to do DDD that it gives me. It could definitely do with better documentation though :) |
Wait...so AS' try got in our way somehow? I need to reproduce this because it shouldn't be possible that dry-types calls `try` on an object which is not a type object.
Re ROM - thank you for your kind words! :)
Cheers
Piotr
…On 17 Dec 2016, 4:19 PM +0200, Andy Shipman ***@***.***>, wrote:
Aha! your comment about optional allowed me to progress. I can specify this as:
attribute :snapshot, Types::Snapshot.default { nil }
to get around the issue I have with ActiveSupport.
So, thanks for all the help. Let me also say that ROM is awesome. I'm enjoying the freedom to do DDD that it gives me.
It could definitely do with better documentation though :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (#115 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAAEKi5EEmwkgrdK7CtIWY5abNA5u4PCks5rI-9ugaJpZM4LMy5t).
|
Sorry for the delay in replying, but yes that's exactly the issue I was having when declaring an attribute as |
@mrship OK I suspect it's a bug in structs + optional. I reported an issue in dry-struct dry-rb/dry-struct#26 |
We have a table (snapshots) that is reused across several entities. The relationship to the other entities is specified by a combination of
parent_id
andparent_type
in that table.I have set up two relations (below) so that I can get as
Snapshot
for aQuestion
.This is all working well, if I use the method directly on the Snapshot relation to get the snapshot. However, if I use that method using
combine_children
in a QuestionRepo then it does not correctly setup thesnapshot
attribute in the result set that ROM returns.Here's the code:
As you can (hopefully) see, I have the correct data in the database [#1] and [#2], the method on the Snapshots relation works correctly [#3], but the
combine_children
call does not.Any thoughts? Am I missing some setup step? Or is this not going to work as I expect?
The text was updated successfully, but these errors were encountered: