Joining tables with a block condition fails with aliased relation

[slicedpan]

Describe the bug

If you have a relation that corresponds to a table with a different name than the table, then joining will fail because the JOIN query will try to join to a table with the relation name, not the table name. I'm fairly sure this only happens when you pass a block to the join method to set the join conditions.

To Reproduce

The following snippet will exhibit this bug:

require "rom"

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(:my_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)
  end

  conf.relation(:tasks) do
    schema(:my_tasks, infer: true) do
      associations do
        belongs_to(:user)
      end
    end
  end
end

rom.relations[:users].join(rom.relations[:tasks]) do |users:, tasks:|
  tasks[:user_id].is(users[:id])
end.to_a

If you inspect the query before calling to_a you will see the following:

SELECT `users`.`id`, `users`.`name` FROM `users` INNER JOIN `tasks` ON (`my_tasks`.`user_id` = `users`.`id`) ORDER BY `users`.`id`

As you can see, the query is trying to join a table named tasks and not my_tasks as you might expect.

Expected behavior

The JOIN should reference the correct table name when supplying a block with join conditions.

Your environment

• Affects my production application: NO
• Ruby version: ruby 2.6.1p33 (2019-01-30 revision 66950) [x86_64-linux]
• OS: Ubuntu 16.04

[abrthel]

Everyone ok with changing
https://github.com/rom-rb/rom-sql/blob/master/lib/rom/sql/relation/reading.rb#L1097

other.name.to_sym -> other.name.dataset.to_sym

[solnic]

Everyone ok with changing
https://github.com/rom-rb/rom-sql/blob/master/lib/rom/sql/relation/reading.rb#L1097
other.name.to_sym -> other.name.dataset.to_sym

@abrthel yep! that's clearly a bug with a simple fix like you suggested