On 29 Oct 2007, at 01:39, Mark Reginald James wrote:
>
> Pratik wrote:
>
>> I've uploaded a patch to optimize eager loading, which changes the
>> code to spend less time in ruby -
>> http://dev.rubyonrails.org/ticket/10011
>>
>> The problem is because of following line in
>> associations.rb:#con
Pratik wrote:
> I've uploaded a patch to optimize eager loading, which changes the
> code to spend less time in ruby -
> http://dev.rubyonrails.org/ticket/10011
>
> The problem is because of following line in
> associations.rb:#construct_associations :
> collection.target.push(association) unles
On 10/28/07, Danny Burkes <[EMAIL PROTECTED]> wrote:
>
> > Do you wanna whip up a patch with the right UTF codes?
> >
>
> Sure, happy to do it, but is there something wrong with the latest patch
> attached to http://dev.rubyonrails.org/ticket/9975 ? Does it go a bit
> too far?
Seems to work for
> The last patch submitted against the ticket allows you to do this:
It just doesn't feel right to me to depend on your controller name for
this.
Let's try this as a plugin for now and give it a chance to live in the
wild. If this works out for folks writing JSON APIs, we can look at
including
On Oct 27, 9:52 pm, snacktime <[EMAIL PROTECTED]> wrote:
> On Oct 26, 5:55 pm, "Michael Koziarski" <[EMAIL PROTECTED]> wrote:
>
> > > I'm struggling a bit with the best way to override the private create
> > > and update methods. I have an adapter for a non sql backend and I
> > > need to eithe
On 29/10/2007, at 8:57 AM, Hongli Lai <[EMAIL PROTECTED]> wrote:
>
> On Oct 28, 6:59 pm, Rick Olson <[EMAIL PROTECTED]> wrote:
>> I think that's reasonable...
>>
>> Also, perhaps redirect_to with an activerecord model could assume a
>> 303?
>>
>> redirect_to foo_path # 301
>> redirect_to @fo
On Oct 28, 6:59 pm, Rick Olson <[EMAIL PROTECTED]> wrote:
> I think that's reasonable...
>
> Also, perhaps redirect_to with an activerecord model could assume a
> 303?
>
> redirect_to foo_path # 301
> redirect_to @foo # 303
>
> The fact that browsers don't redo the post when reloading sounds like
Looks interesting.
I don't have time to test this but have you tried to eager load several
has_many associations at once (so there are M*N result rows)
and compare the memory consumption of the new approach with the old one?
On P, 2007-10-28 at 18:34 +, Pratik wrote:
> Hi,
>
> I've uploaded
> Do you wanna whip up a patch with the right UTF codes?
>
Sure, happy to do it, but is there something wrong with the latest patch
attached to http://dev.rubyonrails.org/ticket/9975 ? Does it go a bit
too far?
- D
--
Posted via http://www.ruby-forum.com/.
--~--~-~--~~--
Hi,
I've uploaded a patch to optimize eager loading, which changes the
code to spend less time in ruby -
http://dev.rubyonrails.org/ticket/10011
The problem is because of following line in
associations.rb:#construct_associations :
collection.target.push(association) unless
collection.target.incl
> I like that- it's worth mentioning that the non-compliance issue I'm
> having is with non-browsers choking on the to_json output, not browsers.
> So distinguishing between the two seems like a good compromise, if we
> need one.
I don't... But we don't do that for HTML so I'm not sure we have t
> One thing to consider, too, is that this only affects JSON posted on a
> web page, not sent between requests. Perhaps there's something like
> the html_encode helper for JSON:
>
> <%= j @foo.to_json %>
>
I like that- it's worth mentioning that the non-compliance issue I'm
having is with non-
On Oct 28, 12:43 pm, "Rick DeNatale" <[EMAIL PROTECTED]> wrote:
> Thanks to a great suggestion by Josh Susser. I've spent the past two
> days completely re-working the code I submitted in the eariler patch.
>
> The new patch;http://dev.rubyonrails.org/ticket/10012
> accomplishes the same result
> If we can be comfortable we're not introduce a security regression,
> then we can down to the talk about how we encode those values,
> whether it's sane to assume utf-8 encoded strings, and all that other
> good stuff :)
One thing to consider, too, is that this only affects JSON posted on a
web
On Oct 28, 5:01 am, Hongli Lai <[EMAIL PROTECTED]> wrote:
> On Oct 28, 11:02 am, "Michael Koziarski" <[EMAIL PROTECTED]>
> wrote:
>
> > As was mentioned by others, you should really be sending 201, so I'm
> > not even sure this is an issue that merits changing the documentation.
> > I realise
Thanks to a great suggestion by Josh Susser. I've spent the past two
days completely re-working the code I submitted in the eariler patch.
The new patch; http://dev.rubyonrails.org/ticket/10012
accomplishes the same results, but with a much better api.
The earlier patch added a new option for u
Thanks :)
On Oct 25, 9:37 am, Pratik <[EMAIL PROTECTED]> wrote:
> It's a hack done in few hours. No one dare to laugh ;-)
>
> http://tools.assembla.com/svn/corefun
>
> On 10/25/07, mikong <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > I was actually thinking of limiting the script to check only the
> >
On Oct 28, 11:02 am, "Michael Koziarski" <[EMAIL PROTECTED]>
wrote:
> As was mentioned by others, you should really be sending 201, so I'm
> not even sure this is an issue that merits changing the documentation.
> I realise browsers don't support 201 but that's why we have
> respond_to
Seeing t
> All I'm advocating for is valid JSON- I thought that was the Core team's
> position now as well, since they finally addressed the key-quoting issue
> in http://dev.rubyonrails.org/changeset/7697
>
> Am I wrong about that?
No, you're not wrong. All I'm looking for is for people to report
that t
> You're welcome to whatever philosophy you choose to hold to, but
> unless this change will also address the security issue identified,
> it's a complete non-starter ;)
>
Of course < and > should be encoded- but they should be encoded per the
spec, as \u003C' and '\u003E', respectively. They
> If the current core philosophy is that to_json should always generate
> spec-valid JSON (as evidenced by
> http://dev.rubyonrails.org/changeset/7697), then
> http://dev.rubyonrails.org/changeset/6893, which caused this problem,
> was contrary to that philosophy.
You're welcome to whatever philo
> First, thanks for the redirect_to patch. I started with that originally.
> Again because this is a common use case, I figured we need to address it in
> the framework, and it looked to me like the low hanging fruit is submitting
> a documentation patch. Documenting this means teaching people
> http://dev.rubyonrails.org/changeset/7697), then
> http://dev.rubyonrails.org/changeset/6893, which caused this problem,
> was contrary to that philosophy.
>
Damn encoder :-) That's
http://dev.rubyonrails.org/changeset/6893
- D
--
Posted via http://www.ruby-forum.com/.
--~--~-~-
> So, back to the issue at hand, which is that the string encoder for
> ActiveSupport::JSON converts "<" and ">" to '\074' and '\076', when it
> should actually be encoding them as '\u003C' and '\u003E'.
>
+1
If the current core philosophy is that to_json should always generate
spec-valid JSON
24 matches
Mail list logo
