On 16-07-2015 09:34, Matt Jones wrote:
On Jul 15, 2015, at 11:06 AM, Rodrigo Rosenfeld Rosas rr.ro...@gmail.com
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
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 WHERE id
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
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
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 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
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:
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
On Jul 15, 2015, at 11:06 AM, Rodrigo Rosenfeld Rosas rr.ro...@gmail.com
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
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
10 matches
Mail list logo
