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
When functions like where, join, order on relation are given aliased attribute instances they
produce malformed sql. This can happen with the method signature api and block level DSL api.
For example: user_relation.order(user_relation[:name]) would output -> ORDER BY "users"."name" AS 'user_name'
To Reproduce
The following gist reproduces most some of the issues I've found with aliases
require'bundler/inline'gemfiledosource'https://rubygems.org'gem'rom','5.2.1'gem'rom-sql, '3.2.0' gem 'sqlite3' gem 'rspec' # gem 'pry' # gem 'pry-byebug'endRSpec.configure do |config| config.disable_monkey_patching! config.warnings = true config.filter_run_when_matching :focusendRSpec.describe "With aliased attributes return correct results when" do let(:users) { rom.relations[:users] } let(:tasks) { rom.relations[:tasks] } let(:rom) do rom = ROM.container(:sql, 'sqlite::memory') do |conf| conf.default.create_table(:users) do primary_key :id column :name, String, null: false end conf.default.create_table(:tasks) do primary_key :id column :name, String, null: false foreign_key :user_id, :users, null: false end conf.relation(:users) do schema(infer: true) do attribute :name, alias: :user_name end end conf.relation(:tasks) do schema(:tasks, infer: true) do attribute :user_id, alias: :task_key associations do belongs_to(:user) end end end end end before do rom.relations[:users].insert(id: 1, name: 'Jane') rom.relations[:users].insert(id: 2, name: 'John') rom.relations[:users].insert(id: 3, name: 'Shelly') rom.relations[:tasks].insert(id: 1, name: 'Pickupmilk', user_id: 2) rom.relations[:tasks].insert(id: 2, name: 'CallInsurance', user_id: 3) rom.relations[:tasks].insert(id: 3, name: 'CancelPhonePlan', user_id: 3) end describe '#order' dolet(:result){[{id: 1,user_name: "Jane"},{id: 2,user_name: "John"},{id: 3,user_name: "Shelly"}]}it'given block dsl'dorelation=users.order{name}expect(relation.to_a).toeq(result)endit'given attribute instances'dorelation=users.order(users[:name])expect(relation.to_a).toeq(result)endenddescribe'#select'dolet(:result){[{user_name: "Jane"},{user_name: "John"},{user_name: "Shelly"}]}it'given attribute instances'dorelation=users.select(users[:name])expect(relation.to_a).toeq(result)endenddescribe'#join'dolet(:result){[{:id=>2,:user_name=>"John",:task=>"Pick up milk"},{:id=>3,:user_name=>"Shelly",:task=>"Call Insurance"},{:id=>3,:user_name=>"Shelly",:task=>"Cancel Phone Plan"}]}it'given attribute instances'dorelation=users.select_append(tasks[:name].as(:task)).join(:tasks,users[:id]=>tasks[:user_id])expect(relation.to_a).toeq(result)endenddescribe'#where'dolet(:result){[{id: 2,user_name: "John"}]}it'given block dsl'dorelation=users.where{name.is('John')}expect(relation.to_a).toeq(result)endit'given attribute instances'dorelation=users.where(users[:name]=>'John')expect(relation.to_a).toeq(result)endit'given block dsl and attribute instances'dorelation=users.where(users[:name]=>'John'){id.is(2)}expect(relation.to_a).toeq(result)endendend
Expected behavior
I would expect rom to output correct sql when given aliased attributes which can be set during
schema creation using the public api.
Your environment
Affects my production application: NO (but is halting development)
Describe the bug
When functions like
where
,join
,order
on relation are given aliased attribute instances theyproduce malformed sql. This can happen with the method signature api and block level DSL api.
For example:
user_relation.order(user_relation[:name])
would output ->ORDER BY "users"."name" AS 'user_name'
To Reproduce
The following gist reproduces most some of the issues I've found with aliases
Expected behavior
I would expect rom to output correct sql when given aliased attributes which can be set during
schema creation using the public api.
Your environment
The text was updated successfully, but these errors were encountered: