Allow to load associations asynchronously #26
Conversation
casperisfine
force-pushed
the
load-assoc-async
branch
from
e11f03b
to
ec5d51e
Compare
|
|
||
| fixtures :companies, :accounts | ||
|
|
||
| self.use_transactional_tests = false |
There was a problem hiding this comment.
Note to self. With the recent refactor in connection pool / pinned connections, we should actually be able to properly simulate async queries with transactional tests. We just need a lock around the connection.
There was a problem hiding this comment.
@casperisfine We are interested in this - would we have to do anything in the tests themselves?
casperisfine
force-pushed
the
load-assoc-async
branch
from
ec5d51e
to
f30028d
Compare
There was a problem hiding this comment.
@byroot: two questions:
- I am assuming that the changes we will make to the production code will be of the form
<object>.association(:<associated_object>).async_load_target, correct? - What will be the best way for us to get this change for testing in the Core code?
For now yes, this is just to test the internal capability, this isn't likely to be the final "end user API". It's more likely to be something like: post.load_async(:comments, tags, :author)I'm still thinking about it.
Depends what you need. If you just want to test locally or on CI, you can just edit the gem "rails", github: "rails/rails", branch: "main"by: gem "rails", github: "https://github.com/Shopify/rails/pull/26" |
casperisfine
force-pushed
the
load-assoc-async
branch
from
9ecc9d2
to
6eb3d99
Compare
There was a problem hiding this comment.
@casperisfine thanks for this! It LGTM. When do you intend to release this?
|
|
||
| fixtures :companies, :accounts | ||
|
|
||
| self.use_transactional_tests = false |
There was a problem hiding this comment.
@casperisfine We are interested in this - would we have to do anything in the tests themselves?
| first_firm = companies(:first_firm) | ||
|
|
||
| promise = client.load_async(:firm) | ||
| wait_for_async_query |
There was a problem hiding this comment.
Do we need to wait? Should not client.firm wait already?
There was a problem hiding this comment.
We don't need to, it's only for testing purpose to ensure the query is actually executed in the background.
Opening here rather than upstream for now, because this is just exploratory work.
Notes:
belongs_to / has_one / has_manyis quite easy.:throughrelations, but these are rare so not a priority.FYI: @hcmaATshopify @rafaelfranca