Inconsistent access to ROM::SQL::Attribute while querying
wuarmin opened this issue · comments
Hey,
I'm on hanami 1.1 and have some inconsistencies while accessing ROM::SQL::Attributes.
Following code
class StationRepository < Hanami::Repository
def all_by_part_of_name(name)
stations.
where(stations[:name].ilike(name)).
map_to(Station).to_a
end
end
fails with
ArgumentError: wrong number of arguments (given 1, expected 0)
/home/armin/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rom-3.3.3/lib/rom/relation.rb:135:in `call'
/home/armin/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rom-3.3.3/lib/rom/relation/composite.rb:21:in `call'
/home/armin/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rom-repository-1.4.0/lib/rom/repository/relation_proxy.rb:324:in `method_missing'
/home/armin/.rbenv/versions/2.3.1/lib/ruby/2.3.0/delegate.rb:83:in `method_missing'
/home/armin/.devel/essence/essence_backend/lib/essence_backend/repositories/station_repository.rb:12:in `all_by_part_of_name'
/home/armin/.devel/essence/essence_backend/spec/essence_backend/repositories/station_repository_spec.rb:15:in `block (2 levels) in <top (required)>'
If I change code to following, it works.
...
def all_by_part_of_name(name)
stations.
where(root[:name].ilike(name)).
map_to(Station).to_a
end
....
So conclusion is that if I want to access ROM::SQL::Attribute's of repositories-table I have to use root, instead of stations. stations seems to be a composite.
Bit if I use ROM's block syntax root does not work. At rom-block-syntax it seems to be different. At block accessing attributes via root does not work.
stations.
where {
root[:name].ilike(name)
}.
map_to(Station).to_a
At blocks I have to use stations. Sometimes this works, but sometimes not. If not, it fails with:
NoMethodError: undefined method `[]' for Station:Class
/home/armin/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rom-3.3.3/lib/rom/schema/attribute.rb:28:in `[]'
/home/armin/.devel/essence/essence_backend/lib/essence_backend/repositories/station_repository.rb:12:in `block in all_by_part_of_name'
/home/armin/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rom-sql-1.3.5/lib/rom/sql/restriction_dsl.rb:9:in `instance_exec'
/home/armin/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rom-sql-1.3.5/lib/rom/sql/restriction_dsl.rb:9:in `call'
/home/armin/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rom-sql-1.3.5/lib/rom/sql/schema.rb:27:in `restriction'
/home/armin/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rom-sql-1.3.5/lib/rom/sql/relation/reading.rb:357:in `where'
/home/armin/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rom-3.3.3/lib/rom/pipeline.rb:80:in `method_missing'
/home/armin/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rom-repository-1.4.0/lib/rom/repository/relation_proxy.rb:324:in `method_missing'
/home/armin/.rbenv/versions/2.3.1/lib/ruby/2.3.0/delegate.rb:83:in `method_missing'
/home/armin/.devel/essence/essence_backend/lib/essence_backend/repositories/station_repository.rb:12:in `all_by_part_of_name'
/home/armin/.devel/essence/essence_backend/spec/essence_backend/repositories/station_repository_spec.rb:15:in `block (2 levels) in <top (required)>'
UPDATE this failure can be fixed with:
stations_wrapper = self.relations[:stations]
stations.
where {
stations_wrapper[:name].ilike(name)
}.
map_to(Station).to_a
I I couldn't figure out why so far. Maybe somebody has an explanation and can point out, what's the right way to handle such things.
best regards 😄
Hi @wuarmin thanks for reporting this. I'll take a look at it and at least give you some explanation. =p
Heya @wuarmin , are you using postgresql as your DB?
I've nailed part of the problem as our wrapping of the relations in a MappedRelation and already have some ways to fix that. But I just need to be sure if there aren't any other shennanigans going around when using PG. =/
Hi @mereghost!
Thank you for your work. Yes I'm using postgresql. Great to hear that.
@wuarmin Yeah, the fix works in granting consistent access using the relation name (stations
on your example).
I'm writing some tests to ensure that no regression will happen and put up a PR in the next few days.
@mereghost great. I'm looking forward to v1.2.0
Fixed by #478
Thanks!