Re: [Rails-core] Question: Is ::Upload used anywhere in Rails?

[Al]

Backport this to earlier versions?

On Thursday, August 8, 2019 at 3:09:50 PM UTC-4, Rafael Mendonça França 
wrote:
>
> I hope this commit answers the question 
> https://github.com/rails/rails/commit/fb5f8d4f86a4a08705d6e9b39b44203df22ab50d
> .
>
> On Aug 8, 2019, at 14:51, Al > wrote:
>
> Is "::Upload" used anywhere in Rails? Sorbet is asking.
>
>
> https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch.rb 
> :84: 
> autoload :Upload
>
> Thanks,
> Al
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonra...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/rubyonrails-core/17242cbd-2721-4494-9a5a-21f5c2ab46d1%40googlegroups.com
>  
> 
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rubyonrails-core/881a2ff7-ebe5-49ee-9795-ec8ac51f8ea4%40googlegroups.com.

Re: [Rails-core] Question: Is ::Upload used anywhere in Rails?

[Rafael Mendonça França]

I hope this commit answers the question 
https://github.com/rails/rails/commit/fb5f8d4f86a4a08705d6e9b39b44203df22ab50d 
.

> On Aug 8, 2019, at 14:51, Al  wrote:
> 
> Is "::Upload" used anywhere in Rails? Sorbet is asking.
> 
> https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch.rb 
> 
>  :84: autoload :Upload
> 
> Thanks,
> Al
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/rubyonrails-core/17242cbd-2721-4494-9a5a-21f5c2ab46d1%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rubyonrails-core/176331EC-507E-41D7-88F3-5D1C8388BD8A%40gmail.com.

[Rails-core] Question: Is ::Upload used anywhere in Rails?

[Al]

Is "::Upload" used anywhere in Rails? Sorbet is asking.

https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch.rb 
:84: 
autoload :Upload

Thanks,
Al

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rubyonrails-core/17242cbd-2721-4494-9a5a-21f5c2ab46d1%40googlegroups.com.

Re: [Rails-core] [Question] Is plucking columns from joined table a legit usage?

[James Coleman]

At the very least on PostgreSQL (I only say that because that's where
I'm the most familiar) there's no reason to need to cast based purely
on the class's attributes -- the database result knows the database
types of the columns returns. For example, my relation_to_struct gem
does this for arbitrary calculated columns using only the ActiveRecord
APIs: 
https://github.com/jcoleman/relation_to_struct/blob/master/lib/relation_to_struct/active_record_relation_extension.rb#L26

I believe `pluck` should guarantee the same.

On Sat, Apr 20, 2019 at 1:28 AM Stan Lo  wrote:
>
> From the examples in documents, it looks like AR#pluck is mainly for 
> retrieving columns from the same table. Like
> Post.pluck(:author_id)
>
> But we can also find some people using pluck for joined tables' columns, like
> Post.joins(:author).pluck("author.name", :title)
>
> And normally this works fine, except for cases like 
> https://github.com/rails/rails/issues/36042.
>
> class Post < ActiveRecord::Base
>   enum status: {
> a: "a",
> b: "b",
> c: "c"
>   }
>   has_many :comments
> end
>
> class Comment < ActiveRecord::Base
>   enum status: {
> red: "red",
> green: "green",
> blue: "blue"
>   }
>   belongs_to :post
> end
>
> class BugTest < Minitest::Test
>   def test_association_stuff
> post = Post.create!(status: "a")
> post.comments << Comment.create!(status: "blue", not_enum: "blue")
>
> expected = [["a", "blue", "blue"]]
> actual = Post.includes(:comments).pluck(:status, "comments.status", 
> "comments.not_enum")
> assert_equal expected, actual
>   end
> end
>
>
> After digging into the issue, I think plucking joined tables' columns is kind 
> of a misuse of pluck. Here's the source code of pluck
>
> def pluck(*column_names)
>   if loaded? && (column_names.map(&:to_s) - @klass.attribute_names - 
> @klass.attribute_aliases.keys).empty?
> return records.pluck(*column_names)
>   end
>
>   if has_include?(column_names.first)
> relation = apply_join_dependency
> relation.pluck(*column_names)
>   else
> klass.disallow_raw_sql!(column_names)
> relation = spawn
> relation.select_values = column_names
> result = skip_query_cache_if_necessary { 
> klass.connection.select_all(relation.arel, nil) }
> result.cast_values(klass.attribute_types)
>   end
> end
>
>
> And the cause of the issue above is
>
> result.cast_values(klass.attribute_types)
>
> Pluck seems assume it'll only be used for the same table, so it uses the 
> original class' attribute types to cast column values (in this case, the 
> Post's attribute types). Hence when the joined table's columns need different 
> casting methods (like different enum definitions), Rails may get confused. 
> (For generic types like integer, string that won't be a problem though, 
> that's why most people don't have issue). And for our issue example, Rails 
> tried to use Post's status type definition to cast Comment's status type, and 
> as expected it failed.
>
> So my question is, should we have a full support on this behavior? Which 
> means we'd need to be able to cast types for every tables envolved. And this 
> won't be a small change since we now need to get all tables' type 
> definitions. Or we should consider this as a misuse and not receommending 
> using it (or even deprecate it).
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at https://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] [Question] Is plucking columns from joined table a legit usage?

[Stan Lo]

>From the examples in documents, it looks like AR#pluck is mainly for 
retrieving columns from the same table. Like 
Post.pluck(:author_id)

But we can also find some people using pluck for joined tables' columns, 
like 
Post.joins(:author).pluck("author.name", :title)

And normally this works fine, except for cases 
like https://github.com/rails/rails/issues/36042. 

class Post < ActiveRecord::Base
  enum status: {
a: "a",
b: "b",
c: "c"
  }
  has_many :comments
end

class Comment < ActiveRecord::Base
  enum status: {
red: "red",
green: "green",
blue: "blue"
  }
  belongs_to :post
end

class BugTest < Minitest::Test
  def test_association_stuff
post = Post.create!(status: "a")
post.comments << Comment.create!(status: "blue", not_enum: "blue")

expected = [["a", "blue", "blue"]]
actual = Post.includes(:comments).pluck(:status, "comments.status", 
"comments.not_enum")
assert_equal expected, actual
  end
end


After digging into the issue, I think plucking joined tables' columns is 
kind of a misuse of pluck. Here's the source code of pluck

def pluck(*column_names)
  if loaded? && (column_names.map(&:to_s) - @klass.attribute_names - 
@klass.attribute_aliases.keys).empty?
return records.pluck(*column_names)
  end

  if has_include?(column_names.first)
relation = apply_join_dependency
relation.pluck(*column_names)
  else
klass.disallow_raw_sql!(column_names)
relation = spawn
relation.select_values = column_names
result = skip_query_cache_if_necessary { 
klass.connection.select_all(relation.arel, nil) }
result.cast_values(klass.attribute_types)
  end
end


And the cause of the issue above is 

result.cast_values(klass.attribute_types)

Pluck seems assume it'll only be used for the same table, so it uses the 
original class' attribute types to cast column values (in this case, the 
Post's attribute types). Hence when the joined table's columns need 
different casting methods (like different enum definitions), Rails may get 
confused. (For generic types like integer, string that won't be a problem 
though, that's why most people don't have issue). And for our issue 
example, Rails tried to use Post's status type definition to cast Comment's 
status type, and as expected it failed.

So my question is, should we have a full support on this behavior? Which 
means we'd need to be able to cast types for every tables envolved. And 
this won't be a small change since we now need to get all tables' type 
definitions. Or we should consider this as a misuse and not receommending 
using it (or even deprecate it).






-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Question about rc1 in RAILS_VERSION file?

[Rafael Mendonça França]

It needs to be 5.2.0.alpha. We are working on this change.

On Mon, Mar 20, 2017 at 9:23 PM Al  wrote:

> Just saw rc1 for Rails. Have a question.
>
> Does https://github.com/rails/rails/blob/master/RAILS_VERSION in master
> (edge rails) need to be "5.1.0.rc1"?
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at https://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Question about rc1 in RAILS_VERSION file?

[Al]

Just saw rc1 for Rails. Have a question.

Does https://github.com/rails/rails/blob/master/RAILS_VERSION in master 
(edge rails) need to be "5.1.0.rc1"?

Thanks

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Question

[Andrey Molchanov]

Hello there!
What do you think about to inherit classes *ActionView::Template::HTML* and 
*ActionView::Template::Text* from a common class and extract similar 
methods?
Thanks!

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Question about length of ActionDispatch::Routing::Mapper class file

[George Mendoza]

Thanks for sharing your thoughts on the Ctrl-P argument. I agree that code
should be first, and that we should not bend code just to adapt to its
supporting environment. I guess the bigger issues for long/short files are
readability and maintainability. But that's for another discussion :)

On Sat, Sep 19, 2015 at 8:53 PM, Xavier Noria  wrote:

> By the way, I would like to expand a bit on the Ctrl-P argument.
>
> In my mind, code has to be written according to principles that concern
> the code itself. How does client code look like, usage, readability,
> performance, good organization, maintenance, etc.
>
> I never design code to bend to anything outside the code itself. Like
> tests, docs, or editors. Code is first, it is the duty of tests and docs to
> adapt to code, not the other way around.
>
> So, either I am fine with the limitarions of Ctrl-P navigation and run the
> occasional grep, or else I add ctags to the project, or use RubyMine that
> is able to go to definitions robustly out-of-the-box. I would not
> organize my code to satisfy the shortcomings of tool.
>
> (Again, sharing points of view, not meaning others should think like me.)
>
>
>
> --
> Sent from Gmail Mobile
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Ruby on Rails: Core" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/rubyonrails-core/D9-3aqWrSMw/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Question about length of ActionDispatch::Routing::Mapper class file

[Xavier Noria]

By the way, I would like to expand a bit on the Ctrl-P argument.

In my mind, code has to be written according to principles that concern the
code itself. How does client code look like, usage, readability,
performance, good organization, maintenance, etc.

I never design code to bend to anything outside the code itself. Like
tests, docs, or editors. Code is first, it is the duty of tests and docs to
adapt to code, not the other way around.

So, either I am fine with the limitarions of Ctrl-P navigation and run the
occasional grep, or else I add ctags to the project, or use RubyMine that
is able to go to definitions robustly out-of-the-box. I would not organize
my code to satisfy the shortcomings of tool.

(Again, sharing points of view, not meaning others should think like me.)



-- 
Sent from Gmail Mobile

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Question about length of ActionDispatch::Routing::Mapper class file

[George Mendoza]

Hello Rails team,

I posted this question in the Ruby on Rails Talk mailing list a week ago. 
However, I wasn't able to get a lot of replies there. I'm hoping I'd have 
better luck here :)

Our team lead and I recently discussed the pros and cons of breaking up a 
long source file into multiple source files. I tend to prefer one class per 
file, because I find the individual files easier to read and easier to find 
(with ctrl-p in Sublime). On the other hand, our team lead doesn't have 
issues with long source files. He argues that they are quite common in 
open-source projects. As an example, he pointed to the 
ActionDispatch::Routing::Mapper 

 class in Rails as a case of a long file with multiple inline classes.

I'm curious to learn the intent behind keeping all the contents of Mapper 
class within a single file. What were the advantages of taking this 
approach?

Thanks,

George Mendoza
Philippines

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Question marks in SQL string literals

[Alexey Noskov]

Hi all!

Recently I discovered that AR tries to treat question marks inside SQL 
string literals as parameters, however this behaviour shows in very rare 
cases, for example (very odd, but...):

User.where("NOT EXISTS (#{ Comment.where('user_id = users.id AND body ILIKE 
?', '%?').to_sql }) AND created_at > ?", Date.yesterday).to_sql

It will fail, because inner SQL will contain qmark inside of literal, which 
AR will count as query parameter 
(https://github.com/rails/rails/blob/master/activerecord/lib/active_record/sanitization.rb#L129),
 
but there is only one argument.

However, this will work (because AR skip parameter binding when no 
arguments are given):
User.where("NOT EXISTS (#{ Comment.where('user_id = users.id AND body ILIKE 
?', '%?').to_sql })").to_sql

So is it a minor bug or a correct behaviour?

P.S. Unlike AR, database drivers don't try to bind qmarks inside of string 
literals

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] question about how to set up an active record adapter to prefer use of prepared statements...

[Aaron Patterson]

On Tue, Sep 11, 2012 at 11:21:19AM -0700, BobBuck wrote:
> 
> 
> Hi,
> 
> I am writing an active record adapter for our new database and when I run 
> the tests I see lots of statements that could be run as prepared 
> statements, but instead of passing me bindings AR passes me a fully 
> specialized SQL string, not in all cases, but in many. Here is an example:
> 
> SELECT  addrs.* FROM addrs  WHERE addrs.user_id = 153 FETCH FIRST 1 ROWS ONLY
> 
> I do have this hook set up:
> 
> def supports_statement_cache?
>  trueend
> 
> And I added this, but I am not familiar with its function, copying from 
> another driver:
> 
> if @config.fetch(:prepared_statements) { true }
>   @visitor = Arel::Visitors::NuoDB.new self
> else
>   @visitor = BindSubstitution.new self
> end
> 
> Is there anything I need to do to get more statements run as prepared 
> statements instead of ordinary ones?

IIRC, this should be it.  We don't have all statements using bind values
with AR (yet).  Try testing with code like this: SomeModel.find(1)

-- 
Aaron Patterson
http://tenderlovemaking.com/


pgpXoCptCrbXJ.pgp
Description: PGP signature

[Rails-core] question about how to set up an active record adapter to prefer use of prepared statements...

[BobBuck]

Hi,

I am writing an active record adapter for our new database and when I run 
the tests I see lots of statements that could be run as prepared 
statements, but instead of passing me bindings AR passes me a fully 
specialized SQL string, not in all cases, but in many. Here is an example:

SELECT  addrs.* FROM addrs  WHERE addrs.user_id = 153 FETCH FIRST 1 ROWS ONLY

I do have this hook set up:

def supports_statement_cache?
 trueend

And I added this, but I am not familiar with its function, copying from 
another driver:

if @config.fetch(:prepared_statements) { true }
  @visitor = Arel::Visitors::NuoDB.new self
else
  @visitor = BindSubstitution.new self
end

Is there anything I need to do to get more statements run as prepared 
statements instead of ordinary ones?

Thanks in advance,

Bob

-- 
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-core/-/hrGxhA-lYyEJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Question about PATCH method, accepts_nested_attributes_for, and updates to association lists (has_many, HABTM)

[Nick Sutterer]

Steve, I'd be interested in this "Rails JSON media type" as well, but we 
can talk this weekend in Berlin. There is definitely a common behaviour 
that a lot of Rails projects would appreciate for a CRUD-style PATCH where 
the media type defines what will get overwritten, deleted, updated, also, 
with nested models, etc. Defining a media type would help Rails 
understanding that REST is not exposing a CRUD API through JSON.

Nick

On Tuesday, August 14, 2012 5:45:32 PM UTC+2, Steve Klabnik wrote:
>
> > Should I put in a ticket for that? 
>
> This is exactly where feature requests go. So you kinda already did. ;) 
>
> > If you are trying to do a patch, then JSON in the request could be 
> easily 
> > converted to model representation in Rails. But just handling off the 
> > implementation of a patch to the developer leaves a lot up in the air. 
>
> Yep. I've been giving some though to declaring some sort of 'Rails 
> flavored JSON' that would be able to address these kinds of issues, 
> but it's not near the proposal stage yet. We don't know what every 
> application needs, so currently, it's left up to each dev. 
>
> > For example, when parsing a patch, it would seem that there would be 
> some 
> > way to differentiate between the incoming PATCH request specifying an 
> > attribute as nil 
>
> Again, this is the reason why PATCH requires a diff media type be sent 
> to it. Then there's no question. 
>

-- 
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-core/-/B-YVBciO6RUJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Question about PATCH method, accepts_nested_attributes_for, and updates to association lists (has_many, HABTM)

[Steve Klabnik]

> Should I put in a ticket for that?

This is exactly where feature requests go. So you kinda already did. ;)

> If you are trying to do a patch, then JSON in the request could be easily
> converted to model representation in Rails. But just handling off the
> implementation of a patch to the developer leaves a lot up in the air.

Yep. I've been giving some though to declaring some sort of 'Rails
flavored JSON' that would be able to address these kinds of issues,
but it's not near the proposal stage yet. We don't know what every
application needs, so currently, it's left up to each dev.

> For example, when parsing a patch, it would seem that there would be some
> way to differentiate between the incoming PATCH request specifying an
> attribute as nil

Again, this is the reason why PATCH requires a diff media type be sent
to it. Then there's no question.

-- 
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 from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Question about PATCH method, accepts_nested_attributes_for, and updates to association lists (has_many, HABTM)

[Gary Weaver]

Steve,

Thanks! I was under the impression that patch might actually allow patch 
updates in some planned future version of Rails 4 by only specifying 
attributes (and attributes of associated models through 
accepts_nested_attributes_for) that the client requests to update.

If everything is being directed to the update method and then it doesn't 
support actually making patches, that seems like it would mislead more than 
it would actually provide desired functionality. I'm not suggesting PATCH 
be removed, but it would be nice if implementing patching behavior were on 
the roadmap. Should I put in a ticket for that?

If you are trying to do a patch, then JSON in the request could be easily 
converted to model representation in Rails. But just handling off the 
implementation of a patch to the developer leaves a lot up in the air.

For example, when parsing a patch, it would seem that there would be some 
way to differentiate between the incoming PATCH request specifying an 
attribute as nil vs. not specifying the attribute at all in the request 
(and therefore not wanting to set that attribute to nil). While this could 
be handled more simply, if you leave it up to the average developer, they 
might end up writing their own JSON parser and monkey-patching Object to 
add an "undefined" method to return some new Undefined class, so that it 
would appear to be part of syntax until an new type of nil could be added 
to Ruby called "undefined", which would probably never be added... In other 
words, I think handling this sort of thing would be better done on the 
Rails side.

Gary

-- 
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-core/-/D6RVDkM-AIgJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Question about PATCH method, accepts_nested_attributes_for, and updates to association lists (has_many, HABTM)

[Steve Klabnik]

> I'm basically just trying to understand what Rails 4 plans to offer with
> regard to patching,

Here is the relevant commit: https://github.com/rails/rails/commit/002713c64

The commit message gives a pretty decent overview. This is basically
just a baby-step forward; but adding direct support for the method
will allow other people to do exactly what they want.

-- 
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 from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Question about PATCH method, accepts_nested_attributes_for, and updates to association lists (has_many, HABTM)

[Gary Weaver]

Steve,

Thanks for your response!

If you plan to use PATCH, you should figure out what you need and use it.
>

I had read: 
http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-the-new-primary-http-method-for-updates/

It states that:

Because of that, the PATCH method 
was defined in 1995 and standarized later. PATCH is a method that is 
> not safe, nor idempotent, and allows *full and partial updates* and 
> *side-effects 
> on other resources*. In practice, as you see, PATCH suits everyday web 
> programming way better than PUT for updating resources. In Ruby on Rails it 
> corresponds naturally to the way we use update_attributes for updating 
> records. Thus, PATCH is going to be the primary method for updates in Rails 
> 4.0.
>

Rails supports use of accepts_nested_attributes_for to update associated 
models, so I'm curious how these patches could be accomplished easily in 
Rails 4:

1. What would a JSON request look like that could be sent into a controller 
via patch method to only change one field in an associated model, where the 
model being updated accepts_nested_attributes_for the model that has the 
field you want to update?

2. What would a JSON request look like that could be sent into a controller 
via patch method to only remove a single tie record to an association 
without changing the list of associations, to avoid losing other changes 
that have been made to the membership of the collection/list of 
associations? (Does patch require a _destroy on a tie/connecting model? If 
so, would that be bad terminology considering that changes to associations 
as pointed out in http://guides.rubyonrails.org/association_basics.html for 
the Appointment tie models between Physician and Patient is deleted and not 
destroyed when there is a has_many :through relationship and the membership 
list is updated? In that case would a new _remove key on the associated 
model make sense?)

I'm basically just trying to understand what Rails 4 plans to offer with 
regard to patching, especially in the context of Javascript frameworks and 
the like that would be wanting to send/receive JSON to Rails controllers to 
manage not only models, but models and their associations. Just changing 
each model via its own request requires more requests and if there are 
changes that need to be made to specific fields of a model and specific 
fields of its associations in a single transaction, it would be much easier 
to just being able to send in a single patch request to a model that 
defines accepts_nested_attributes_for.

Thanks!
Gary


On Monday, August 13, 2012 6:20:25 PM UTC-4, Steve Klabnik wrote:
>
> This is the reason that the spec for patch[1] specifically requires a 
> diff be sent[2]: 
>
> > The set of changes is represented in a format called a "patch 
> > document" identified by a media type. 
>
> and 
>
> > With PATCH, however, the enclosed entity contains a set 
> > of instructions describing how a resource currently residing on the 
> > origin server should be modified to produce a new version. 
>
> and 
>
> > Further, it is expected that different patch document formats will be 
> > appropriate for different types of resources and that no single 
> > format will be appropriate for all types of resources.  Therefore, 
> > there is no single default patch document format that implementations 
> > are required to support. 
>
> If you plan to use PATCH, you should figure out what you need and use 
> it. I'm not aware of a media type that does diffs in plain JSON at 
> this time. 
>
> 1: http://tools.ietf.org/html/rfc5789 
> 2: http://tools.ietf.org/html/rfc5789#section-2 
>

-- 
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-core/-/YfYQDwoTeB0J.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Question about PATCH method, accepts_nested_attributes_for, and updates to association lists (has_many, HABTM)

[Steve Klabnik]

This is the reason that the spec for patch[1] specifically requires a
diff be sent[2]:

> The set of changes is represented in a format called a "patch
> document" identified by a media type.

and

> With PATCH, however, the enclosed entity contains a set
> of instructions describing how a resource currently residing on the
> origin server should be modified to produce a new version.

and

> Further, it is expected that different patch document formats will be
> appropriate for different types of resources and that no single
> format will be appropriate for all types of resources.  Therefore,
> there is no single default patch document format that implementations
> are required to support.

If you plan to use PATCH, you should figure out what you need and use
it. I'm not aware of a media type that does diffs in plain JSON at
this time.

1: http://tools.ietf.org/html/rfc5789
2: http://tools.ietf.org/html/rfc5789#section-2

-- 
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 from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] Question about PATCH method, accepts_nested_attributes_for, and updates to association lists (has_many, HABTM)

[Gary Weaver]

 

Am interested in the new PATCH method that will be included in Rails 4, but 
have a question/concern, and forgive me if I'm misunderstanding it.

So, if the request parameter _method is set to "patch", the update is 
processed as a patch.

But, let's say you have a model called Airplane and Airplane has a 
collection of FlightCrewMembers which it accepts_nested_attributes_for. You 
get the Airplane resource via a RESTful call to Rails that contains the 
FlightCrewMembers list. Then something needs to make a PATCH to this 
resource and change both an attribute called autopilot_engaged on the 
Airplane while only changing the active_pilot flag of one of the 
FlightCrewMembers. You send this together to ensure that a single 
transaction is wrapped around both the update to autopilot_engaged on the 
Airplane and the active_pilot flag of one of the FlightCrewMembers.

When you send the Airplane resource from the client to the RESTful service, 
you specify one or more FlightCrewMembers in the resource. If you truly 
wanted to patch, you should only have to specify the one FlightCrewMember 
in the Airplane's list of FlightCrewMembers and only specify the 
active_pilot flag on that FlightCrewMember. However, this could also 
indicate that the other 4 of the 5 FlightCrewMembers are no longer on the 
plane if the patch is also allowed to change which FlightCrewMembers are 
assocated with the Airplane. But that would mean you'd have to specify the 
list of ids of FlightCrewMembers in the patch request, which could have the 
unintended result of altering the list of members if one member had really 
left the plain at the same time (perhaps they are still on the ground and 
one just left the Airplane to run up the jetway).

So, does there need to be new attributes on the Airplane resource that is 
passed in by the client to indicate whether the membership list of 
FlightCrewMembers is being altered on Airplane? And instead of just passing 
in a list of objects that only specify the id of the associated object to 
update the list, shouldn't the client (since they are providing a patch) be 
able to only specify which members are be deleted?
 
Possibly support could be added for a new _remove key on the object to be 
removed from a list? That would seem to be a good name. That way you could 
either use the existing _destroy key that allows you to destroy the 
associated object or could use the new _remove key to just indicate that in 
your patch request you are specifying to remove it from the list.

So, if the _method were "patch", then just specifying a list of objects 
only indicating their IDs wouldn't update the membership of that resource's 
collection. You would need to specify a _remove or _destroy key (depending 
on whether the client wanted to just remove it from the collection or 
actually destroy the object).
 

-- 
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-core/-/PvCRFrUc5e8J.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Question about "KnownIP".tableize

[Colin Law]

On 3 April 2011 22:21, Allen Madsen  wrote:
> It also says, in the docs you linked to:
>
> As a rule of thumb you can think of underscore as the inverse of camelize,
> though there are cases where that does not hold:
>
> "SSLError".underscore.camelize # => "SslError"
>
> So the situation you're talking about is a known shortcoming.

That is true, thanks.

Colin

-- 
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 from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Question about "KnownIP".tableize

[Allen Madsen]

It also says, in the docs you linked to:

As a rule of thumb you can think of underscore as the inverse of camelize,
though there are cases where that does not hold:


"SSLError".underscore.camelize # => "SslError"

So the situation you're talking about is a known shortcoming.

Allen Madsen
http://www.allenmadsen.com


On Sun, Apr 3, 2011 at 5:08 PM, Colin Law  wrote:

> On 3 April 2011 21:21, Ryan Bigg  wrote:
> > Did your rails g generate the KnownIP model or the KnownIp model? Your
> post says both.
>
> Oh, are you sure it says both?
>
> > On 04/04/2011, at 0:20, Colin Law  wrote:
> >> ...
> >> The result (at least I think it is the result of above) is that
> >> rails g model KnownIP
> >> provides a model class KnownIp in known_ip.rb, rather than KnownIP in
> >> known_i_p.rb
>
> It produced a KnownIp model when one might expect it to produce
> KnownIP.  Having investigated further I am pretty sure the problem is
> in ActiveSupport::Inflector#underscore, giving
>
> ruby-1.8.7-p302 > ActiveSupport::Inflector.underscore("KnownIP")
>  => "known_ip"
> ruby-1.8.7-p302 > ActiveSupport::Inflector.underscore("KnownIP").camelize
>  => "KnownIp"
>
> However looking at the intro on [1] I see
> "The Rails core team has stated patches for the inflections library
> will not be accepted in order to avoid breaking legacy applications
> which may be relying on errant inflections. If you discover an
> incorrect inflection and require it for your application, you’ll need
> to correct it yourself (explained below)."
> So this may be a case of "that is just how it is".
>
> Colin
>
> [1] http://api.rubyonrails.org/classes/ActiveSupport/Inflector.html
>
> --
> 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 from this group, send email to
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>

-- 
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 from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Question about "KnownIP".tableize

[Colin Law]

On 3 April 2011 21:21, Ryan Bigg  wrote:
> Did your rails g generate the KnownIP model or the KnownIp model? Your post 
> says both.

Oh, are you sure it says both?

> On 04/04/2011, at 0:20, Colin Law  wrote:
>> ...
>> The result (at least I think it is the result of above) is that
>> rails g model KnownIP
>> provides a model class KnownIp in known_ip.rb, rather than KnownIP in
>> known_i_p.rb

It produced a KnownIp model when one might expect it to produce
KnownIP.  Having investigated further I am pretty sure the problem is
in ActiveSupport::Inflector#underscore, giving

ruby-1.8.7-p302 > ActiveSupport::Inflector.underscore("KnownIP")
 => "known_ip"
ruby-1.8.7-p302 > ActiveSupport::Inflector.underscore("KnownIP").camelize
 => "KnownIp"

However looking at the intro on [1] I see
"The Rails core team has stated patches for the inflections library
will not be accepted in order to avoid breaking legacy applications
which may be relying on errant inflections. If you discover an
incorrect inflection and require it for your application, you’ll need
to correct it yourself (explained below)."
So this may be a case of "that is just how it is".

Colin

[1] http://api.rubyonrails.org/classes/ActiveSupport/Inflector.html

-- 
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 from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Question about "KnownIP".tableize

[Ryan Bigg]

Did your rails g generate the KnownIP model or the KnownIp model? Your post 
says both.



On 04/04/2011, at 0:20, Colin Law  wrote:

> Using Rails 3.0.5 is it expected that
> ruby-1.8.7-p302 > "KnownIP".tableize
> => "known_ips"
> rather than "known_i_ps" as I had expected?
> 
> The result (at least I think it is the result of above) is that
> rails g model KnownIP
> provides a model class KnownIp in known_ip.rb, rather than KnownIP in
> known_i_p.rb
> 
> Colin
> 
> -- 
> 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 from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.
> 

-- 
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 from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] Question about "KnownIP".tableize

[Colin Law]

Using Rails 3.0.5 is it expected that
ruby-1.8.7-p302 > "KnownIP".tableize
 => "known_ips"
rather than "known_i_ps" as I had expected?

The result (at least I think it is the result of above) is that
rails g model KnownIP
provides a model class KnownIp in known_ip.rb, rather than KnownIP in
known_i_p.rb

Colin

-- 
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 from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Question about exception notification

[Teng Siong Ong]

sorry. this group is only for the discussion of the development of the
framework. since you have already posted your question here:
http://groups.google.com/group/rubyonrails-talk, you should be good.

On Fri, Sep 24, 2010 at 6:03 PM, badnaam  wrote:

> This is for rails 2.3.5
>
> can the manual exception notification be used in models or just
> controller?
>
> Thanks
>
> --
> 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 email to
> rubyonrails-core+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>

-- 
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 email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] Question about exception notification

[badnaam]

This is for rails 2.3.5

can the manual exception notification be used in models or just
controller?

Thanks

-- 
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 email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] Question/possible bug on ActiveRecord serialize and STI

[Dustin Lundquist]

I've been running into a problem where ActiveRecord 2.3.5 isn't
deserializing a serialized column in derived classes:
http://pastie.org/856463
I've been able to replicate this test with Ruby 1.8.6p369, 1.8.7p72,
and 1.8.7p174 on different systems, any thoughts?


Dustin Lundquist

-- 
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 email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Question about coding style in Rails 3 source

[Joshua Peek]

On Mon, Jan 11, 2010 at 11:46 PM, Jeff  wrote:
> Hi,
>
> I've noticed that some of the commits to rails edge lately are using a
> style where instance variables of a class start with a leading
> underscore.
>
> Like in this commit: 
> http://github.com/rails/rails/commit/8cb594a2e1808cd7d93f3593afed0414016fc56f
>
> I see this variable:
>
> @_env

This specific example shouldn't be using the "private ivar" naming
style since the Rails module is not an inheritable class.

-- 
Joshua Peek
-- 
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 email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Question about coding style in Rails 3 source

[Yehuda Katz]

We use @_ivars in cases where an instance variable is to be used internally
in a module that will be mixed into a user's class or a class that will be
inherited by a user's class.

For instance, we use @_ivars in ActionController::Base and modules mixed
into ActionController::Base.

Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325


On Mon, Jan 11, 2010 at 9:46 PM, Jeff  wrote:

> Hi,
>
> I've noticed that some of the commits to rails edge lately are using a
> style where instance variables of a class start with a leading
> underscore.
>
> Like in this commit:
> http://github.com/rails/rails/commit/8cb594a2e1808cd7d93f3593afed0414016fc56f
>
> I see this variable:
>
> @_env
>
> I'm guessing it's to avoid naming conflicts when the module is
> included in a class?  I don't recall seeing this style in other Ruby
> libraries (it harkens back to my C++ days), so I'm just wondering if
> there's a particular purpose behind it; and whether people who look to
> contribute code should be adopting this style, and in what situations.
>
> Thanks,
> Jeff
>
> --
> 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 email to
> rubyonrails-core+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
>
>
-- 

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 email to rubyonrails-core+unsubscr...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] Question about coding style in Rails 3 source

[Jeff]

Hi,

I've noticed that some of the commits to rails edge lately are using a
style where instance variables of a class start with a leading
underscore.

Like in this commit: 
http://github.com/rails/rails/commit/8cb594a2e1808cd7d93f3593afed0414016fc56f

I see this variable:

@_env

I'm guessing it's to avoid naming conflicts when the module is
included in a class?  I don't recall seeing this style in other Ruby
libraries (it harkens back to my C++ days), so I'm just wondering if
there's a particular purpose behind it; and whether people who look to
contribute code should be adopting this style, and in what situations.

Thanks,
Jeff
-- 
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 email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] Question about Rails 2.x behavior

[Yehuda Katz]

In Rails 2.x, if you have an XML template, and try to render a template 
that does not have an XML version, but does have an HTML version, it 
will be rendered. XML and HTML are just examples; this is true for any 
two mime types.

Is this behavior important? First of all, I'm not sure this is the right 
behavior, since it's possible to be explicit about the format you wish 
to use and rendering a template from a different MIME seems likely to be 
a mistake. Second of all, it requires us to widen our search criteria 
when looking for subsidiary templates (like partials), and prevents us 
from efficiently caching the template for a given format (instead, we 
need to cache the template for a given Array of formats, which is much 
less efficient).

I also think that restricting subsidiary templates would be consistent 
with other (non-breaking) fixes we've done to ensure that layouts match 
the MIME type of the template they are wrapping (which allowed us to 
eliminate the exempt_from_layout hacks).

Thanks for your attention,

-- Yehuda

--~--~-~--~~~---~--~~
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 from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Question about _pick_template and template_file_extension

[Daniel Guettler]

Hi,

quick question about _pick_template and template_file_extension.
The template_file_extension is extracted in the method but not used
later to find a template. This leads to the case were a template isn't
found and Template.new(template_path, view_paths) is called which
triggers a performance warning.
E.g. if you have a template in: app/views/information/scripts.js
which you try to include with: render :file => 'information/
scripts.js'
the lookup isn't checking for "information/scripts.js" in the
view_paths if the rendered format for the page is html.
Only these cases are checked:
self.view_paths["#{template_file_name}.#{template_format}"] and
self.view_paths[template_file_name]
which both don't exist.
So the question is if there shouldn't be a case in between like so:
if template = self.view_paths["#{template_file_name}.#
{template_format}"]
  template
elsif template_file_extension && template = self.view_paths["#
{template_file_name}.#{template_file_extension}"]
  template
elsif template = self.view_paths[template_file_name]
  template

Thanks, Daniel
--~--~-~--~~~---~--~~
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 from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] question on AR Mysql#query_with_result

[rogerdpack]

It seems that by default the Mysql adapter uses
instance.query_with_result = true [the default] for its queries.
Is there any special reason for that?
Thanks!
-=R

--~--~-~--~~~---~--~~
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 from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] question about activerecord test_numeric_fields in base_test.rb

[knightsc]

There's a test for activerecord called test_numeric_fields in
base_test.rb. here's the test

  def test_numeric_fields
m = NumericData.new(
  :bank_balance => 1586.43,
  :big_bank_balance => BigDecimal("1000234000567.95"),
  :world_population => 60,
  :my_house_population => 3
)
assert m.save

m1 = NumericData.find(m.id)
assert_not_nil m1

# As with migration_test.rb, we should make world_population >=
2**62
# to cover 64-bit platforms and test it is a Bignum, but the main
thing
# is that it's an Integer.
assert_kind_of Integer, m1.world_population
assert_equal 60, m1.world_population

assert_kind_of Fixnum, m1.my_house_population
assert_equal 3, m1.my_house_population

assert_kind_of BigDecimal, m1.bank_balance
assert_equal BigDecimal("1586.43"), m1.bank_balance

assert_kind_of BigDecimal, m1.big_bank_balance
assert_equal BigDecimal("1000234000567.95"), m1.big_bank_balance
  end

The numeric_data table is defined like this

CREATE TABLE `numeric_data` (
  `id` INTEGER NOT NULL auto_increment PRIMARY KEY,
  `bank_balance` decimal(10,2),
  `big_bank_balance` decimal(15,2),
  `world_population` decimal(10),
  `my_house_population` decimal(2),
  `decimal_number_with_default` decimal(3,2) DEFAULT 2.78
) TYPE=InnoDB;

My question is with assert_kind_of Integer, m1.world_population. Why
would world_population be an integer. It seems like this test makes an
assumption about how a particular database stores the actual data type
internally. To me when defining a field as decimal(10) or lets say
numeric(10) both of these really should be of kind BigDecimal since
that's what the database field is stored as, it's just that the
BigDecimal object should have no numers after the decimal point. Am I
just way off here? Making this assumption for a database like Firebird
where two different databases might be a different dialect. For
example decimal(15,2) in dialect 1 firebird is really a double
precision underneath, in dialect 3 it's really being stored as a
bigint. Regardless of how the database is storing this underneat the
Firebird driver (correctly in my opinion) translate this to a
BigDecimal column. The test above then fails because it's looking for
wrong types. Anyone have any thoughts on this?


--~--~-~--~~~---~--~~
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 from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Question about Module#parent

[Xavier Noria]

Module#parent is defined in introspection.rb as

  def parent
parent_name = name.split('::')[0..-2] * '::'
parent_name.empty? ? Object : parent_name.constantize
  end

And dependencies.rb defines Class#const_missing as

  def const_missing(class_id)
if [Object, Kernel].include?(self) || parent == self
  super
end
...
  end

If the || is not redundant there has to be a self different from
Object whose parent is himself, but I can't figure out an example.
Just to understand that line, is there any?

-- fxn


--~--~-~--~~~---~--~~
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 from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] question about idiom for loading files in initializer.rb

[giles bowkett]

Hi --

This started as a question in ruby-talk. It's about this line of code:

eval(IO.read(init_path), binding, init_path)

This idiom appears in initializer.rb, in v1.2.3, for loading
environment files and plugin init files. (On Edge, the plugin stuff is
moved to another file, but the same idiom's still used in that file,
and you'll see it used for the env files in initializer.rb on Edge as
well.)

The question was, why use this idiom instead of load or require?

My assumption is that the answer is this idiom gives you flexible
bindings, but if anyone could verify that, or correct me, I'd totally
appreciate it. I don't actually see the binding passed being declared
anywhere, so it kind of puzzles me.


Thanks,
Giles


--~--~-~--~~~---~--~~
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 from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] question about ActiveRecord::Base.reset_subclasses

[Xavier Noria]

Which is the purpose of the loops (wrapped to avoid word wrapping)

   klass.instance_variables.each { |var|
 klass.send(:remove_instance_variable, var)
   }
   klass.instance_methods(false).each { |m|
 klass.send :undef_method, m
   }

in ActiveRecord::Base.reset_subclasses? Why is not enough to  
remove_const reloadable subclasses?

-- fxn 


--~--~-~--~~~---~--~~
 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 from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---