Hi guys,
I don't think that the changes made to the behavior of #all in 4.0 are a very
good idea.
I can see that you no longer need to call all in as many cases as you did
before - that's fine, just don't call it if you don't want it. But that
doesn't mean you never need it or that people
Can we please call the new try something else, and leave try doing what it
already does?
The new behavior was discussed at the time #try originally went in, and, with
some dissenters, it was agreed that it was less useful for most people because
any typo now becomes an expression that returns
1.
You are using the wrong method. If you want the query always you call it
you should use #load
2.
Using #load you will know exactly when the query is done
3.
#sum with block is not recommended since it will load all the object in
memory. This is why it was
I did some review in the code and in a relation, `#load` checks for
`loaded?` so if the relation is still loaded it will not do the query. The
only way right now to reload a relation is using `#reload`.
Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca
On
Can you show me some of the many places where your app now breaks because
we don't raise an exception on #try?
Also, this is why we do major releases, so we can break backwards
compatibility in order to improve the API.
Having #try! be the exception raising version of #try makes perfect sense
I would create an issue if I could replicate the issue in a new
application, but I couldn't yet.
If I can isolate the problem I'll create a new issue.
Em 27-02-2013 01:10, Andrew Kaspick escreveu:
Open a github issue for the problem; it won't be addressed otherwise.
On Tue, Feb 26, 2013 at
Ok, I could finally replicate the issue in development mode for a new
application when I disable the turbolinks gem.
In my application it also happens in production and all other
environments but at least if this is fixed for development mode it could
also fix for my other environments.
Here's the task I alluded to if anyone is interested:
https://gist.github.com/blatyo/5047690
Allen Madsen
http://www.allenmadsen.com
On Thu, Feb 21, 2013 at 3:26 PM, Allen Madsen allen.c.mad...@gmail.comwrote:
At Gazelle, we essentially copy the migration rake tasks and call them
iterations.
On Feb 27, 2013, at 4:42 AM, Will Bryant wrote:
Hi guys,
I don't think that the changes made to the behavior of #all in 4.0 are a very
good idea.
I can see that you no longer need to call all in as many cases as you did
before - that's fine, just don't call it if you don't want it.
I think Rafael has already answered your questions, but as the person
who made the changes I'm happy to answer any further questions if you
have them?
On 27/02/13 13:31, Rafael Mendonça França wrote:
I did some review in the code and in a relation, `#load` checks for
`loaded?` so if the
This looks like pretty much what I think should be available, only
difference being the ability to specify what table to record the running to
keep db:migrate free from non db concerns
Sent from my iPad
On 27 Feb 2013, at 14:40, Allen Madsen allen.c.mad...@gmail.com wrote:
Here's the task I
Hey everyone! I am pumped to announce that Rails 3.2.13.rc1 has been released!
If no regressions are found I will release 3.2.13 final in two weeks, on March
13, 2013. If you find one, please [Open an Issue on
GitHub](https://github.com/rails/rails/issues/new) so that I can fix it before
the final
On 28/02/2013, at 11:17 , Jon Leighton j...@jonathanleighton.com wrote:
#reload will always run the query.
If I'm misunderstanding the use case please provide some examples.
Hmm. But you can't run reload on a scope to get an array - it returns a
relation, which as per previous emails
Or all(true)
On Wed, Feb 27, 2013 at 4:25 PM, Will Bryant will.bry...@gmail.com wrote:
On 28/02/2013, at 11:17 , Jon Leighton j...@jonathanleighton.com wrote:
#reload will always run the query.
If I'm misunderstanding the use case please provide some examples.
Hmm. But you can't run
Most other enterprise-y languages (esp. Java+Hibernate, .NET+NHibernate,
.NET+Entity Framework) reinforce deferred execution of queries: the query
is not executed until it is enumerated. This is now the exact same behavior
as those platforms.
Calling .sum() on an association, before you've
Hi Jarrett,
As per previous emails, the problem is that you can't now force it to do a
query using any particular method. Associations will cache if you enumerate
them and so will not behave in that simple way.
Yes we have tests and yes it does show that this kind of change breaks things.
http://edgeguides.rubyonrails.org/association_basics.html#controlling-caching
It looks like clearing the cache and going to the DB is quite easy. I don't
believe your statement is accurate that you can't force a fresh, enumerated
query. And the cache is reset per request, which is a very short
The thing that's got worse is having to write different code for associations
vs. relations. Currently #all will behave exactly the same way on both, which
is very useful because you can write code on a model class that works the same
way whether it's working on a global scope or just an
Only apps that have bugs. But that's the thing - currently you find out about
the bugs, now you won't.
Remember how great it was when we had to write ActionScript and it just
silently swallowed all the errors and you couldn't find out where your code was
breaking?
No? It wasn't great, it
19 matches
Mail list logo
