So very sorry about that misdirected reply.
On Oct 2, 2012, at 9:45 PM, "Andrés Mejía" wrote:
Thanks Geoff, whatever that means.
On Tue, Oct 2, 2012 at 3:19 PM, Geoff Harcourt wrote:
> OK, pushed. I can't push my own database data up, so I'll get four
> questions up there for you.
>
> -Geoff
>
Thanks Geoff, whatever that means.
On Tue, Oct 2, 2012 at 3:19 PM, Geoff Harcourt wrote:
> OK, pushed. I can't push my own database data up, so I'll get four
> questions up there for you.
>
> -Geoff
>
> --
> Geoff Harcourt
>
> On Tuesday, October 2, 2012 at 4:07 PM, dburry wrote:
>
> One of the g
Any Rails release timeline announcements are generally wrong, anyway.
On Monday, 1 October 2012 at 9:49 AM, Jeremy Walker wrote:
>
>
> On 1 October 2012 00:43, Steve Klabnik (mailto:st...@steveklabnik.com)> wrote:
> > Soonish. There are some things that are blocking the release, but
> > they
OK, pushed. I can't push my own database data up, so I'll get four questions up
there for you.
-Geoff
--
Geoff Harcourt
On Tuesday, October 2, 2012 at 4:07 PM, dburry wrote:
> One of the great things I like about rails is not always being tied to full
> backwards compatibility causing a
One of the great things I like about rails is not always being tied to full
backwards compatibility causing a more and more bloated core every major
release. In my mind a plugin that puts everything back would solve that
issue, for those who need it.
That other objection still gives me pause t
There's also the little issue of the world not all using only English. A
full Unicode-aware case insensitivity is even more inefficient than a
regular ascii-only one... but in practice might be required in just as many
cases as an ascii one...
Dave
On Tuesday, October 2, 2012 12:15:25 PM UTC-
Is there a use case where you wouldn't just do something like...
validates :numbers, inclusion: { in: ['one', 'two'] }
def numbers
read_attribute(:numbers).try(:downcase)
end
i.e. Is there a particular reason why you still want the values to be
stored/presented with potentially different case
2.kilobytes(prefix: :si) would make sense to be 2000, if anyone's
interested in doing so. -1 on everything else.
On Tue, Oct 2, 2012 at 2:29 PM, Allen Madsen wrote:
> This pull request poses two problems in my mind. The changes are not
> backwards compatible, which could lead to some serious head
This pull request poses two problems in my mind. The changes are not
backwards compatible, which could lead to some serious head scratching.
Secondly, even though they're a standard now, they're not commonly used,
which leads to more head scrathing.
Allen Madsen
http://www.allenmadsen.com
On Tue
Can someone review pull #7345 (and related #7350)? Is those features
allowed to be in rails or not?
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-cor
I'm -1 for this.
On Tue, Oct 2, 2012 at 4:53 AM, Jarl Friis wrote:
> One of the greatest things about rails is that it is so
> standards-compliant,
> no other framework that I have seen have complied to the
> HTTP standard (think REST) in such a degree that Rails does. Kudos to
> you all for tha
Aha, nevermind, there is a way to do it that I missed, e.g.:
has_one :home_address, :serializer => SomeAddressSerializer
so that a serializer can be used that in turn uses serializers, etc. as
required for that specific view.
On Monday, October 1, 2012 5:22:10 PM UTC-4, Gary Weaver wrote:
>
>
On 2012-10-02, at 6:46 AM, svoop wrote:
> And maybe the gem even makes it into Rails 4.
As Steve said, it already did :P
--
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
> It feels wrong to use validations for this. Then again, if Rails 4 moves
> away from attr_accessible towards strong_parameters (which essentially
> shifts mass assignment protection from the model to the controller),
> validations will soon be the only way to protect attributes in the model.
I'm not voting for or against it, but if this does become a feature, the option
name should probably be :case_insensitive so as to match the uniqueness
validation option.
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To view this disc
One of the greatest things about rails is that it is so standards-compliant,
no other framework that I have seen have complied to the
HTTP standard (think REST) in such a degree that Rails does. Kudos to
you all for that.
I think we (Rails community) should follow the line of standards
compliance
This is a mailing list for discussion about development of the rails
framework itself. For questions about using rails, please post to
https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-talk
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails:
I've already asked this on StackOverflow with no luck on answer -
http://stackoverflow.com/questions/12617237/rails-3-2-force-prepared-statements
Simplified case:
Hotel.find(1) - executes using prepared statement
SELECT "hotels".* FROM "hotels" WHERE "hotels"."id" = $1 LIMIT 1 [["id", 1]]
Hotel
I want to add case_sensitive option to inclusion validation. This will
allow to do:
validates :numbers, :inclusion => { :in => %(One Two), :case_sensitive =>
false }
Does it make a sense?
Thanks.
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: C
19 matches
Mail list logo
