Conversation
|
|
||
| attribute = @columns.first.split(".").second.to_sym | ||
|
|
||
| relation = relation.where(model.arel_table[attribute].gt(@position.first)) |
There was a problem hiding this comment.
This change is to demonstrate that using arel_table does not treat the id column as strings in the generated SQL:
# original SQL:
Stripe::Fee.where("id > ?", 3).to_sql
=> "SELECT `stripe_fees`.* FROM `stripe_fees` WHERE (id > '3')"
# SQL with arel_table:
Stripe::Fee.where(Stripe::Fee.arel_table[:id].gt(3)).to_sql
=> "SELECT `stripe_fees`.* FROM `stripe_fees` WHERE `stripe_fees`.`id` > 3"MySql is lenient and allows such comparison, however BigQuery raises an exception for this behaviour:
Google::Cloud::InvalidArgumentError: No matching signature for operator > for argument types: INT64, STRING.
There was a problem hiding this comment.
Yeah we had noticed that too, making use of arel_table does the trick, however it becomes very cumbersome to convert database table names into constantized classes in the jobiteration layer.
I just had a pairing session with @bony2023 and we managed to patch the bigquery adapter to prevent the coercion.
All details in this PR: https://github.com/Shopify/activerecord-bigquery-adapter/pull/4
There was a problem hiding this comment.
That being said we may want to revisit that coercion on the Mysql queries too 👍
as you pointed out even though it is lenient about it ain't ideal.
etravassos
force-pushed
the
eo_custom_database
branch
from
1198efe to
ad7d29a
Compare
etravassos
changed the title
| end | ||
| end | ||
|
|
||
| def initialize(relation, columns = nil, position = nil) |
There was a problem hiding this comment.
2 participants
…rings