Are there any rationalies to make queries obtained by joining scope to
be
readonly? I read some old posts (pre-rails3) that joins adds additional
columns to record so that ActiveRecord doesn’t know how to update that
fields, but actually I don’t see that fields. For example I write model
class Order < ActiveRecord::Base
has_and_belongs_to_many :executors, class_name: ‘Specialist’,
join_table:
‘order_executors’
scope :by_executor, ->(executor_id) {
joins(:executors).where(specialists: {id: executor_id} ) }
end
and make query Order.by_executor(1) so that I get:
Order Load (2.0ms) SELECT “orders”.* FROM “orders” INNER JOIN
“order_executors” ON “order_executors”.“order_id” = “orders”.“id” INNER
JOIN “specialists” ON “specialists”.“id” =
“order_executors”.“specialist_id” WHERE “specialists”.“id” = 1
=> [#<Order id: 20, orderable_id: 11, orderable_type: “PlanDevelopment”,
client_id: 1, completion_status: “finished”, created_at: “2013-05-13
20:48:19”, updated_at: “2013-05-14 00:36:38”, price:
#BigDecimal:67e5898,‘0.14E2’,9(36)>]
I see no additional columns but Order.by_executor(1).first.readonly? is
true. Is that necessary?
p.s. Yes I know that I can set readonly(false) or explicitly specify
select
clause - so that records won’t become readonly. But I want to understand
why this blocking behavior is necessary (if it is still true) and what
damage will be possible without readonly mark? Also I don’t understand,
how
can I shot myself if I explicitly set readonly(false).
On Tuesday, May 14, 2013 10:26:56 AM UTC+1, Илья Воронцов wrote:
end
#BigDecimal:67e5898,‘0.14E2’,9(36)>]
I see no additional columns but Order.by_executor(1).first.readonly? is
true. Is that necessary?
p.s. Yes I know that I can set readonly(false) or explicitly specify
select clause - so that records won’t become readonly. But I want to
understand why this blocking behavior is necessary (if it is still true)
and what damage will be possible without readonly mark? Also I don’t
understand, how can I shot myself if I explicitly set readonly(false).
This might be a hangover from the past - I think active record didn’t
use
to default to orders.* - the default select clause was select *.
The danger is only if you do select columns from the other tables. This
can
either prevent saves (because your object has an attribute that doesn’t
exist for the model) or mask existing data, eg if both of the joined
tables
have a client_id column and you do select * then the activerecord object
will have a single client_id attribute that has only one of those
values.
Fred
On 14 May 2013 11:12, Frederick C. [email protected]
wrote:
join_table: ‘order_executors’
=> [#<Order id: 20, orderable_id: 11, orderable_type: “PlanDevelopment”,
what damage will be possible without readonly mark? Also I don’t understand,
will have a single client_id attribute that has only one of those values.
Should the OP be using includes rather than joins?
Colin
On Tuesday, May 14, 2013 11:14:56 AM UTC+1, Colin L. wrote:
Should the OP be using includes rather than joins?
Hard to tell.
Fred
Thank you, Frederik.
I think in my case joins is better because I don’t want any orders
except
those having exact executor (with includes I’ll get lots of orders
without
any executor at all, if I understand its behavior right)
I tried to get specialist_id and got nothing. So it looks, there is
actually no column foreign columns on default join.
On Tuesday, May 14, 2013 10:26:56 AM UTC+1, Илья Воронцов wrote:
I see no additional columns but Order.by_executor(1).first.readonly? is
true. Is that necessary?
One other thing: inspect only ever shows columns from the model table - If
you change the select clause to orders.*, order_executors.specialist_id
then you’d get the same inspect output but your object would respond to
specialist_id
Fred