-
-
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
Select columns are always overidden when using combine #287
Comments
I literally ran into this exact same problem a few moments ago. An additional gist showing this bug in action with rom v4.2.1 & rom-sql v2.4.0: |
After a bit of sleuthing, I believe the issue lies with rom schemas, If you change the selections of the relation at the dataset level then the relations schema doesn't get updated. Then when the schema gets updated with parent id during the combine the new selections override the selections from the default dataset. |
Does it work when you define the schema explicitly? I think this is the only way to make it work now. Schemas are inferred from canonical db schemas, and if you override the dataset, it's gonna be impossible to infer the schema reliably from that dataset, as it only provides column names IIRC. Unless I'm mistaken.../cc @flash-gordon |
In my case explicit schema definitions didn't work and as far as I know, there isn't a way to explicitly define attributes on a schema that targets another table. The problem is that when rom-sql qualifies the column name it points to the wrong table. eg: My only solution so far was to either "fix" the dataset every time after modifying it or using hackity hack hacks to replace the relation with a fixed up schema in the container.
Agreed, I don't think that's possible and I'm sure the solution will require some type of manual intervention which only makes sense for usecases like this. |
Thanks to @mrship I've stumbled upon a solution to this issue. TL;DR; I've updated my reproduction script to show the fix The ProblemDuring the finalization process the default dataset for the relation can be manipulated and columns/attributes from other tables can be joined into the relation. When using the resulting relation to query for its data the results are returned as you'd expect - as in all extra added attributes are returned. However if you then combine that relation into another relation suddenly all of your extra attributes are no longer apart of the returned results. Whats HappeningModifying the dataset during finalization does not also modify the schema. The reason we don't see the issue right after finalization is because the schema isn't called to modify the relation probably because it's just assumed they're in the same state. Then when combining the relation into another relation the schema is applied to the relation with the modified dataset and the extra joined attributes are discarded as there are no definitions for those attributes in the schema. A SolutionWhen joining two tables at the dataset level, the joined attributes need to be explicitly defined in the relations schema. However to do that, each of those attributes will also need to be explicitly qualified to the joined table's name through the use of the class Region < ROM::Relation[:sql]
schema(infer: true) do
attribute :base_gdp, Types::Strict::String.meta(qualified: :regions_start_pos)
end
dataset do
select(:id, :name, :base_gdp).join(:regions_start_pos, region_id: :id)
end
end As you can see other attributes for Solnic did mention this idea above but until mrship came along I didn't know how to qualify an attribute to another table during finalization. Final Notes
|
Hello,
when combining an aggregate, ie:
and having
employees
relation:the selected columns within
dataset
block are always ignored and the defaults are used, ie:However, when you query using the relation, ie:
it works as expected.
Complete example:
The text was updated successfully, but these errors were encountered: