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
There is a concept of "synthetic" or "calculated" attributes - you can construct an attribute value using various model fields.
Then you can even construct "synthetic" relationships (setting a right foreign_key, afilter and a customized assignment. Please take a note that these relationships won't have any representation in corresponding models (it will only require simple attr_accessor model fields since it looks like your model has to satisfy respond_to?(<relation_name>)).
Its all good when you want to read these relationships - include them in the request and you won't have any problems at all. But it all changes when you want to set these relationships (e.g. when creating a resource) and use these values in persistence lifecycle (e.g. in a before_save callback): you simply either won't have access to it (when using has_one or has_many) or you will mess up the underlying adapter-related logic (e.g. when using belongs_to it will try to set value in the corresponding <relation>_id column).
What about the idea of having these "synthetic" relationships on the resource level and make them available in the persistence lifecycle (e.g. set other model fields based on the values from these relationships)?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
There is a concept of "synthetic" or "calculated" attributes - you can construct an attribute value using various model fields.
Then you can even construct "synthetic" relationships (setting a right
foreign_key
, afilter
and a customized assignment. Please take a note that these relationships won't have any representation in corresponding models (it will only require simpleattr_accessor
model fields since it looks like your model has to satisfyrespond_to?(<relation_name>)
).Its all good when you want to read these relationships - include them in the request and you won't have any problems at all. But it all changes when you want to set these relationships (e.g. when creating a resource) and use these values in persistence lifecycle (e.g. in a
before_save
callback): you simply either won't have access to it (when usinghas_one
orhas_many
) or you will mess up the underlying adapter-related logic (e.g. when usingbelongs_to
it will try to set value in the corresponding<relation>_id
column).What about the idea of having these "synthetic" relationships on the resource level and make them available in the persistence lifecycle (e.g. set other model fields based on the values from these relationships)?
Beta Was this translation helpful? Give feedback.
All reactions