Hello everyone!
There have been many times when I needed to work with a relation in small
chunks. E.g. deleting or updating large number of rows while allowing the
database to work on other tasks in between. This is specially useful if the
number of affected rows is very large and we need to th
Hello everyone!
There have been many times when I needed to work with a relation in small
chunks. E.g. deleting or updating large number of rows while allowing the
database to work on other tasks in between. This is specially useful if the
number of affected rows is very large and we need to th
On 16-07-2015 09:34, Matt Jones wrote:
On Jul 15, 2015, at 11:06 AM, Rodrigo Rosenfeld Rosas
wrote:
Today a colleague was playing in another branch trying the ruby-saml gem to
play with SAML. When he was back to the master branch all requests failed for
apparently no reason. This is related
I'm happy to provide some real code from our app if that helps?
What I don't understand is why there needs to be a way to reload has_many but
not a way to reload has_one.
In our apps most has_ones are related to a has_many, for example picking the
"active" one.
We need to reload the has_many
I'm comfortable with those trade-offs. Barring any compelling real world
code shining a different light on the discussion than what we've covered so
far, I don't think we're going to make any additional progress discussing
it.
On Thursday, July 16, 2015 at 3:12:56 PM UTC+2, will.bryant wrote:
>
Oh, sorry, I explained that badly.
I’m not saying it’s a performance problem doing two queries. I’m saying it’s
causing unintended side-effects, because when you do the query on the parent it
resets the attributes, including blowing away unsaved changes. This is
absolutely undesirable if you
I'd be happy to consider some real code from a real project that shows the
use of reloading a single has_one association in a performance hotspot
where two ID lookups are proving to be a problem. But for the time being,
I'm content with the trade off that has collection#reload and record#reload
I think Al’s suggestion here is a good one. It gets away from the single API
to reload any type of association, but at least it’s possible to do the
association reload when ya need it, and it's crystal clear what is happening.
> On 16/07/2015, at 02:00 , Al Tenhundfeld wrote:
>
> Another ide
On Jul 15, 2015, at 11:06 AM, Rodrigo Rosenfeld Rosas
wrote:
> Today a colleague was playing in another branch trying the ruby-saml gem to
> play with SAML. When he was back to the master branch all requests failed for
> apparently no reason. This is related to this (it was trying to instanti
I think you’re right that we can’t have complete parity, but then as you said,
it would be good to have a single API.
It does works well right now having the same API to always get the fresh
association loaded, and it is useful to be able to definitely get the current
record, even if you don’t
I think the first assumption to challenge is that we can have parity
between a collection and a single object. I don't think we can or should.
An array of strings does not have parity with a single string.
So project.manager.reload will call ActiveRecord::Base#reload, so that's a
Manager.find(i
OK, so what about the has_one case?
Say Project has_one :manager, and project.manager is already loaded (which did
a "SELECT * FROM managers WHERE project_id = ?"), will project.manager.reload
do another "SELECT * FROM managers WHERE project_id = ?", or will it do a
"SELECT * FROM managers WHER
project.documents.reload.first would reload the documents association, then
grab the first entry in that array – not trigger another find(id). Like
calling #load, but ignoring whether it had already been loaded.
On Thursday, July 16, 2015 at 12:53:31 AM UTC+2, will.bryant wrote:
>
> So are you s
13 matches
Mail list logo