Hi Benjamin,
This isn't really a valid use case. The way most of us would tackle
something like this is to write a helper that lazy-loads the value in
question, and call this from the view. This helper can exist in the
controller class, if it needs access to your controller methods, and be
# update_attribute is expected to update the specified attribute, not
other ones. Thus it is violating POLA
This is why you never want to rely on validates_uniqueness_of. It's
essentially a convenience for generating pretty error messages. Use your
DB's unique constraints to validate
On Tuesday, December 11, 2012 6:35:48 AM UTC-5, Rodrigo Rosenfeld Rosas
wrote:
But I find this more consisent:
post[:dotted.column].like('zomg%')
than this:
post.__send__(:dotted.column).like('zomg%')
You could actually support both syntaxes, but if you do so you wouldn't be
able to
On Monday, December 10, 2012 4:08:06 PM UTC-5, Rodrigo Rosenfeld Rosas
wrote:
What if a column is named class? I'd rather prefer something like that:
Post.where { |post|
post[:title].like('zomg%') | post[:class].like('bbq%')
}
In Squeel's specific case, the DSL object is a
:
https://github.com/rails/rails/commit/08f3f30994d37f6f44acfac801f82fc43127fc78
.
I don't think there's a quick (and also correct) way to fix this
behavior, without modifying more than this one method. Jon or Aaron
might tell me I'm wrong, though. :)
--
Ernie Miller
http://metautonomo.us
--
You
On Mar 30, 2011, at 7:18 PM, Aaron Patterson wrote:
I'll be on vacation. :-D
Fixed that for you. :)
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe
On Mar 22, 2011, at 11:26 AM, Gerő Zoltán wrote:
Hi all,
I need a little help. On Ubuntu ImageMagick packages installed. When I try to
install rmagick gem I got this:
...
checking for ImageMagick version = 6.4.9... no
Can't install RMagick 2.13.1. You must have ImageMagick 6.4.9 or
On Mar 16, 6:15 pm, J Smith dark.pa...@gmail.com wrote:
I know this sort of feature has the potential to be abused and lead to
SQL injection attacks, so as a sanity check, I figured I'd check to
see if this sort of feature would be useful or if I'm as crazy as I
may potentially be for bringing
On Feb 16, 2011, at 4:53 AM, Colin Law clan...@googlemail.com wrote:
HI
I notice on Rails 3.0.4 that the following two statements generate
different results.
State.where(:abbreviation = 'TX').where(:abbreviation = 'NE')
SQL: SELECT `states`.* FROM `states` WHERE (`states`.`abbreviation` =
On Feb 16, 2011, at 6:38 AM, Will Bryant will.bry...@gmail.com wrote:
On Thu, Feb 17, 2011 at 12:21 AM, Ernie Miller er...@metautonomo.us wrote:
Since your example above used a string in the second where call, it
didn't result in an Arel::Nodes::Equality, so it wasn't ORed.
Even on just
On Feb 16, 7:24 am, Ernie Miller er...@metautonomo.us wrote:
Sound arguments. I didn't implement collapse_wheres, just in case a
witch hunt starts. I was just the first person awake this morning to
pose the answer. :)
The change probably shouldn't have made it into a point release, but I
of my head. Happy to be corrected, though.
--
Ernie Miller
http://metautonomo.us
http://github.com/ernie
http://twitter.com/erniemiller
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to rubyonrails-core
(off topic: this discussion is good to see, as I will be taking it into
account on the metawhere rewrite)
So, since this thread and another are currently ongoing relating to complex
queries and the handling of ARel predicates, I thought I'd make a quick
announcement that the MetaWhere
On Feb 16, 2011, at 7:19 PM, Nicolás Sanguinetti wrote:
The definitely weirds me out.
I haven't looked at the source, but why aren't you overriding ==? (a
link to rtfm is fine, I'm just lazy :))
Honestly, I don't know. I thought about it, but something about overriding ==
even in this
On Feb 15, 2011, at 5:07 AM, Robert Pankowecki
robert.pankowe...@gmail.com wrote:
o = Organization.first
o.people.includes(:addresses).each do |p|
puts p
puts p.addresses
end # 2 queries are executed, normal and for eager loading addresses
but
o.people.loaded? = false
Is that a bug or
On Feb 13, 2011, at 3:22 AM, Prem Sichanugrist sikand...@gmail.com wrote:
I've been discussed the possibility of exposing ARel power with the core team
too, and found out that they thing ARel API is not mature enough to be
exposed. Maybe we should wait :)
In another hand, they don't like
On Feb 13, 2011, at 1:36 PM, Robert Pankowecki wrote:
Wouldn't it be possible to implement the sexy api with blocks ?
var = 12
# meta_where
User.where(:id.gt var)
# another implementation
User.condition { id.gt var }
Evaluate the the block in different scope in which title method
On Feb 13, 2011, at 12:42 PM, Chris Eppstein wrote:
is it really that likely that your app is going to have a better use
for something like Symbol#matches than to get an ARel Matches node?
Case-in-point: the mongoid gem defines Symbol#matches. Libraries that do this
have a myopic view of
On Feb 13, 2011, at 1:37 PM, Ted Han wrote:
DataMapper has moved away from core patching (as we too think it's a bad
idea). The symbol extensions that monkey patch core are opt-in now for
legacy support, and i (amongst others) think it should go away all together.
DataMapper's extended
children_people
and landed on the same table name), and creates table name collisions.
The patch at
https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/6423 fixes
the regression and adds a test to cover it in the future.
--
Ernie Miller
http://metautonomo.us
http://github.com
On Feb 10, 1:27 pm, Ernie Miller er...@metautonomo.us wrote:
On Feb 10, 2011, at 1:21 PM, Aaron Patterson wrote:
On Tue, Feb 08, 2011 at 12:54:40PM -0800, Brian Cardarella wrote:
Would the core team be open to the removal of the '' alias for
ActiveRecord::Relation#merge?
Yes
When supplying a :limit option to accepts_nested_attributes_for, I found it a
little bit surprising that records which are about to be destroyed count
against the limit. From
ActiveRecord::NestedAttributes#assign_nested_attributes_for_collection_association:
if options[:limit]
On Feb 4, 2011, at 3:30 PM, Paul wrote:
Rails is great and most things just work easily. However, I've never
been able to get a definite answer on whether one should do,
validates :parent, :presence = true
or,
validates :parent_id, :presence = true
given,
class Parent
end
value in supplying :conditions to a polymorphic
belongs_to, given the potential for major differences in the table being
queried, might be debatable, but that's a separate issue. :)
Thanks in advance!
--
Ernie Miller
http://metautonomo.us
http://github.com/ernie
http://twitter.com/erniemiller
contain
supporting software that's used in an integration, for instance.
Put another way, vendor is the place for third-party (vendor) support files.
--
Ernie Miller
http://metautonomo.us
http://github.com/ernie
http://twitter.com/erniemiller
--
You received this message because you are subscribed
In my opinion, the Rails version number should reflect the changes to
the Rails API. The user-facing API did not see major changes due to
the ARel rewrite.
As the author of two gems (MetaWhere and MetaSearch) that are heavily
dependent on ARel for their functionality, I released updated gems an
help figuring out the layout of ARel 2, please drop me an e-mail. I've spent
enough time digging around in it and submitting patches in both 1.x and 2.x
that I should be able to help. That failing, Aaron's always been very
responsive, in my experience.
--
Ernie Miller
http://metautonomo.us
elsewhere. Naturally, a uniq won't catch a situation as described above, since
includes_values contains a symbol, :comments, and a hash, {:comments =
:moderations}.
Thanks in advance!
--
Ernie Miller
http://metautonomo.us
http://github.com/ernie
http://twitter.com/erniemiller
--
You received
. :)
On Sep 8, 2010, at 2:58 PM, Ernie Miller wrote:
Hey all,
In troubleshooting a failing test for MetaSearch against 3-0-stable, I came
across some undesirable (from my side, anyway) behavior in
http://github.com/rails/rails/commit/bf87528b53f1422708ec0188d126cfca824ddc5c.
A simple one
method I can find, in AR::Base, will not get the failures
to stop.
This is with Ruby 1.9.2-p0.
Any insights (or even confirmations I'm not insane) would be appreciated. :)
-Ernie
--
Ernie Miller
http://metautonomo.us
http://github.com/ernie
http://twitter.com/erniemiller
--
You received
FormHelper needs a read method, too. You can return a blank string if
you like but you need to respond_to the field name in question.
You're most likely doing something that's not playing nicely with this
commit's change to value_before_type_cast:
I took a quick glance at
http://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/middleware/remote_ip.rb,
and if I understand your description of the problem on the ticket, it may very
well be the same old behavior that's been in Rails for ages. I wrote about it
in detail a
So I currently have these helpers in MetaSearch because I use them when I
create search forms myself, but I extracted them the other day for a post on
forrst.com and I started to wonder why we don't already have something like
this in Rails. Is the general consensus that this kind of stuff
On Jul 10, 2010, at 7:41 AM, Rodrigo Rosenfeld Rosas rr.ro...@gmail.com wrote:
Ok, let me understand this better. I've just noted we are talking about a
plugin, MetaWhere and not about Rails core behavior, right? bundle show
doesn't list the meta-where plugin as a dependency of Rails...
On Jul 9, 2010, at 12:37 PM, Rodrigo Rosenfeld Rosas wrote:
In Sequel, it is possible to call a sql method to see the generated SQL
from a Sequel object. I missed this in ActiveRecord for a long time. I guess
this is possible for ActiveRecord in Rails 3 since it is using Arel which
takes
On Jul 9, 2010, at 6:57 PM, Rodrigo Rosenfeld Rosas wrote:
Is it difficult to add some method to ActiveRecord that displays exactly the
SQL that will be run, or that would be run if eager loading was set? I mean,
maybe some methods like eager_sql and lazy_sql? I don't know
ActiveRecord's
On Jul 9, 2010, at 7:33 PM, Rodrigo Rosenfeld Rosas wrote:
I don't think it would be terribly difficult, no -- it'd basically be doing
arel.to_sql or a partial version of find_with_associations depending on the
result of eager_loading? that looks something like this and sticking it in
I think the article entitled Named Scopes Are Dead had some good
insights along those lines.
http://www.railway.at/2010/03/09/named-scopes-are-dead/
In the Rails 3 app I've been working on, my scopes are just class
methods like shown there.
On Jul 2, 2010, at 6:57 AM, Paul Campbell
/roadio/roadio/config/routes.rb:6
On a related note, time for me to go back and change my class method
definitions back to scopes. :)
On Jul 2, 2010, at 7:58 AM, Pratik wrote:
I swear I had fixed this. Will have another look.
On Fri, Jul 2, 2010 at 12:54 PM, Ernie Miller er...@metautonomo.us
On Jul 2, 2010, at 9:11 AM, Paul Campbell wrote:
defining an attribute based on a Ruby keyword (private).
I'm pretty sure this isn't the case, since there's no private method
name. Interestingly, it's very difficult to come up for a name in this
that isn't a potential collision.
On Jul 2, 2010, at 9:11 AM, Paul Campbell wrote:
defining an attribute based on a Ruby keyword (private).
I'm pretty sure this isn't the case, since there's no private method
name. Interestingly, it's very difficult to come up for a name in this
that isn't a potential collision.
I
List,
It's been a couple of weeks with no eyes on this simple patch, so I
thought I'd ping the list again in the hopes that someone could give it a quick
once-over. Thanks in advance!
-Ernie
On May 25, 2010, at 10:30 AM, Ernie Miller wrote:
...and it's my fault. :(
Anyway, I have
On May 27, 2010, at 12:51 PM, Daniel Schierbeck wrote:
Xavier, I for one never use jRails -- in fact, neither do most of the
rails devs i know. We do, however, use jQuery.
The JavaScript helpers in Rails 2.3 were rather ugly, from a jQuery point
of view, which probably explains why not that
...and it's my fault. :(
Anyway, I have a fix at
https://rails.lighthouseapp.com/projects/8994/tickets/4679. Two lines of code,
and a a test. Sorry!
-Ernie
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send
On Apr 23, 11:12 am, Ernie Miller er...@metautonomo.us wrote:
While working on this, I came upon what I believe is a bug in a
relatively unused part of the JoinDependency/eager_loading code
pertaining to find_with_associations, though I may be mistaken.
I've put up a lighthouse ticket
On Apr 20, 9:50 pm, Norman Clarke nor...@njclarke.com wrote:
Definitely looks like a cool idea for a plugin though. You should keep
working on it.
I've got an alternate take on the concept up at
http://github.com/ernie/meta_where/tree/autojoin now.
I think I like this one better, and it seems
I've been fiddling around a bit with the concept of adding inferred
join capabilities to a gem I've been working on.
The general idea, to me, is one that feels so Rails-like (as in,
principle of least surprise) that I was kind of surprised it wasn't
already in.
The goal: If you're selecting
On Apr 20, 2010, at 9:42 PM, Pratik pratikn...@gmail.com wrote:
I suppose you could override Relation#build_where
def build_where(*args)
if result = super
case args.first
when Hash
# Figure out table names from *args here and add them to
join_values or something
Thanks to a discussion with Pratik on #rails-contrib today, I decided
to roll this into a gem instead:
http://github.com/ernie/meta_where
Consider the request for feedback on the patch revoked. :)
Thanks!
On Apr 12, 5:08 pm, Ernie Miller er...@metautonomo.us wrote:
I could use some eyes
would optimize one better than the other.
-Ernie Miller
http://metautonomo.us
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to rubyonrails-c...@googlegroups.com.
To unsubscribe from this group, send
I could use some eyes on
https://rails.lighthouseapp.com/projects/8994/tickets/4368
if anyone has the time.
Summary of the change:
Similar to PredicateBuilder's existing support for 'table.column' =
'value', this patch enables 'column#method' = 'value'.
For instance,
On Apr 9, 9:06 pm, Matt Jankowski jankow...@gmail.com wrote:
It looks like a recent documentation commit finally removed references
to this method...
http://github.com/rails/rails/commit/c6372d604952a8eef16ce73a06814aa1...
In lieu of having #proxy_options available, is there another method
On Apr 8, 9:47 pm, Joe Smith unknown_kev_...@hotmail.com wrote:
That breaks left to right readability pretty badly. I really would like a
better solution for negating predicates and predicate chains, but I'm not
sure what.
I agree that I don't much like the way it just dangles there like
I agree that I don't much like the way it just dangles there like
that, but I don't see any other way to accomplish what's desired. In
working with it, I find that it helps to imagine yourself back in the
90s for a moment.
User name equals Bill or user name equals Ted... NOT!
OK, maybe
Hi all. I was hoping to get some feedback on a patch to rails/arel I've put
together. Not really sure where else to get some eyes on this, since Lighthouse
doesn't seem appropriate given the separation of rails/arel from rails/rails.
http://gist.github.com/360075
This patch adds support for
Err, minor correction.
users[:name].matches_any('%Joe%', '%Bob%') is the syntax. I wrote the
patch note last night and wasn't quite awake I guess. :)
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to
56 matches
Mail list logo
