Re: [Rails-core] [ActiveRecord] scope for collection associations
In Rails 4 you should be able to do:
class Post
has_many :comments, - { visible }
end
On 21/05/13 23:41, Caleb Thompson wrote:
I'm considering implementing a feature by which a collection
association might limit the results.
By default, a collection association returns all values where the
foreign key on the `belongs_to` or `has_and_belongs_to` model matches
the parent object's primary key. These results can be filtered using the
`conditions` option, but that requires that other models have knowledge
of the parent model's table structure.
The feature I'm proposing is to add a `scope` option to collection
associations which takes a symbol representing a scope (or class mehtod)
defined on the associated model class.
A basic example would look like this:
class Comment
belongs_to :post
def self.visible
where(deleted_at: nil)
end
end
class Post
has_many :posts, scope: :visible
end
In the above example, `post.comments` would return `Comment` instances
whose `post_id = post.id` and whose `deleted_at = NULL`, providing basic
soft-deletion functionality.
While the same effect could be achieved with a declaration such as
`has_many :posts, conditions: ['deleted_at = ?', nil]`, that betrays
knowledge of the implementation of deletion on `Post` and would break if
the implementation were changed to a boolean value for deletion rather
than a timestamp field.
If I were to work on adding this functionality into ActiveRecord, is it
something that core might entertain merging?
Thank you,
Caleb Thompson
--
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.
--
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] #all changes in 4.0
On 28/02/13 05:30, Will Bryant wrote: 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 association. I don't understand what you mean. Can you give an example of the two different bits of code you have to write? BTW, the per-request caching mechanism is query caching, which is different to the loadedness caching that associations do, which is the reason to_a is not a consistent replacement for #all, and why I want at least a method that always does a query (#query, for example). Again, I don't understand. Please provide before/after code so I can respond to a specific use case. On 28/02/2013, at 18:19 , Jarrett Meyer jarrettme...@gmail.com mailto:jarrettme...@gmail.com wrote: 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 time. The only thing I can think of that would require this kind of functionality is a database trigger or other out-of-sequence activity. On Feb 27, 2013, at 11:38 PM, Will Bryant will.bry...@gmail.com mailto:will.bry...@gmail.com wrote: 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. That's why I'm complaining. Cheers, Will On 28/02/2013, at 15:16 , Jarrett Meyer jarrettme...@gmail.com mailto:jarrettme...@gmail.com wrote: 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 enumerated, will alter the query to perform a SELECT SUM(...). Obviously, this fails on anything that doesn't exist in the database. If you want to .sum() in memory, you must enumerate the collection first (calling .ToArray() in .NET will do this). I don't know if the author of this deferred execution has experience with these other ORM's, but the behavior is now identical. Employee.all vs. Employee.all.to_a is not that big of a deal. And you should expect breaking changes with a major version number. That's why your code is covered by tests, right? Signed, An-ex-.NET-developer-turned-Rubyist -- Jarrett Meyer Email: jarrettme...@gmail.com mailto:jarrettme...@gmail.com Web: JarrettMeyer.com http://jarrettmeyer.com/ Twitter: @jarrettmeyer http://twitter.com/jarrettmeyer On Wed, Feb 27, 2013 at 6:09 PM, Will Bryant will.bry...@gmail.com mailto:will.bry...@gmail.com wrote: That's better than nothing, but #all returns a relation now, which is half the problem (like when you need to sum methods not columns, for eg.). On 28/02/2013, at 12:00 , Duncan Beevers duncanbeev...@gmail.com mailto:duncanbeev...@gmail.com wrote: Or all(true) On Wed, Feb 27, 2013 at 4:25 PM, Will Bryant will.bry...@gmail.com mailto:will.bry...@gmail.com wrote: On 28/02/2013, at 11:17 , Jon Leighton j...@jonathanleighton.com mailto: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 doesn't behave the same. So are you saying we should use .reload.to_a everywhere instead of #all? That really seems like a worse API than #all and this is a very common operation. Is it really worth changing #all to be nearly useless and have no direct to do that? Could we at least have a method that does this, say query? -- 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 mailto:rubyonrails-core%2bunsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com mailto: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
Re: [Rails-core] #all changes in 4.0
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 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 Wed, Feb 27, 2013 at 10:13 AM, Rafael Mendonça França rafaelmfra...@gmail.com mailto:rafaelmfra...@gmail.com wrote: 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 deprecated. The query method is there. It is called |#load| now. Rafael Mendonça França http://twitter.com/rafaelfranca https://github.com/rafaelfranca On Wed, Feb 27, 2013 at 6:42 AM, Will Bryant will.bry...@gmail.com mailto:will.bry...@gmail.com 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. But that doesn't mean you never need it or that people who do need it should not have it available. 1. Yes you can use to_a in many cases, but it behaves differently - for example if you have an association, to_a will return the cached target if the association has already been loaded. You absolutely need a way to run an actual query when you want the latest results. to_a cannot be relied upon to do this in all cases. Note lack of a second query: irb(main):006:0 p = Project.first Project Load (0.2ms) SELECT projects.* FROM projects ORDER BY projects.id ASC LIMIT 1 = #Project id: 1, created_at: 2013-02-27 09:38:49, updated_at: 2013-02-27 09:38:49 irb(main):007:0 p.tasks.to_a Task Load (0.2ms) SELECT tasks.* FROM tasks WHERE tasks.project_id = ? [[project_id, 1]] = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] irb(main):008:0 p.tasks.to_a = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] irb(main):010:0 p.tasks.all DEPRECATION WARNING: Relation#all is deprecated. If you want to eager-load a relation, you can call #load (e.g. `Post.where(published: true).load`). If you want to get an array of records from a relation, you can call #to_a (e.g. `Post.where(published: true).to_a`). (called from irb_binding at (irb):10) = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] irb(main):011:0 p.tasks.all DEPRECATION WARNING: Relation#all is deprecated. If you want to eager-load a relation, you can call #load (e.g. `Post.where(published: true).load`). If you want to get an array of records from a relation, you can call #to_a (e.g. `Post.where(published: true).to_a`). (called from irb_binding at (irb):11) = [#Task id: 1, project_id: 1, created_at: 2013-02-27 09:38:52, updated_at: 2013-02-27 09:38:52, #Task id: 2, project_id: 1, created_at: 2013-02-27 09:38:53, updated_at: 2013-02-27 09:38:53] 2. It's very important that queries run at the point you think they do in any application that uses locks or concurrency. Again, if you don't use locks or concurrency, fine - don't call the query methods. But many people do and they need to be able to run the queries to make this work. 3. It's not true that you no longer need to care whether you have an array or a relation. For example, methods like sum with a block need arrays, as the deprecation makes clear: irb(main):009:0 p.tasks.sum(:id) DEPRECATION WARNING: Calling #sum with a block is deprecated and will be removed in Rails 4.1. If you want to perform sum calculation over the array of
Re: [Rails-core] PostgreSQL bulk alter
On 07/11/12 19:59, Gabriel Sobrinho wrote: There's a reason to postgresql adapter do not supports bulk alter? I think there's no reason other than that nobody has implement it yet, so go for it. -- http://jonathanleighton.com/ -- 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] 3-1-stable: AR XML serialization tests broken for anyone else?
On 14/09/12 06:07, Steve Jorgensen wrote: Oh -- good to know. If I submit a trivial non-security pull request, is it likely to be accepted? If you submit a PR against 3.1 with the sole purpose of fixing broken tests, I'll happily merge. We'll need those tests to work if/when there are future security patches to apply anyway. -- http://jonathanleighton.com/ -- 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] Re: Excessive redundant object allocation in AR
On 12/09/12 17:29, Masterleep wrote: It could be implemented in Rails by using a container class to hold the database field names that are used as the keys inside the AR @attributes hash, and reusing the same string object across instances. Those strings are frozen anyway so the concern about modification doesn't apply. Based on the ObjectSpace data, that one change would have a large impact on the number of allocated subobjects for each AR model instance. To be honest I think we should just change @attributes to be keyed by symbols. I don't see that there is a DoS vector in doing this since the keys aren't going to come from user input (however, I do need to think about that a bit more before I say so confidently). I changed @attributes_cache to be keyed by symbols recently which lead to a nice speed up in attribute access (before then we were creating a new string every time you call an attribute method). It should be noted that these things could theoretically be optimised at the implementation level. I did some benchmarking a while back and there was no difference between using symbols and strings in @attributes on JRuby. However on a practical level, I think we should change it. I'm interested to hear what Mr T. Love thinks. -- http://jonathanleighton.com/ -- 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] Behavior of first_or_create
On 24/07/12 21:29, Matt Jones wrote: On Jul 24, 2012, at 4:04 PM, Andrés Mejía wrote: I would definitely expect User.where(:first_name = 'Scarlett').first_or_create(:last_name = O'Hara) to call User.create(:first_name = 'Scarlett', :last_name = O'Hara) if that's not what's happening then I think it's a bug and should be fixed. Matt, do you have a minimal app that shows the problem? I would like to write a test case for Rails that shows this strange behavior. Nope, that's not exactly what I observed; I'll try again. That code *does* call the create correctly, if there are no users with the correct first_name. The confusing part to me was that it wasn't quite the same as this: User.where(:first_name = 'Scarlett').find_or_create_by_last_name(O'Hara) The latter includes a condition on last_name in the find, where the former does not. This behaviour is intentional. The dynamic version did actually previously take an options hash of stuff that would get passed to create. So: User.where(:first_name = 'Scarlett').find_or_create_by_last_name(O'Hara, :age = 32) would do: User.where(:first_name = Scarlett, :last_name = O'Hara) and then: User.create(:first_name = Scarlett, :last_name = O'Hara, :age = 32) I believe the rationale is simply that you can put all of your conditions in a where() -- http://jonathanleighton.com/ -- 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] AR deprecated finders
You need to bundle update. On 17/07/12 07:46, Oscar Del Ben wrote: Hi all, I had troubles while running tests on Active Record: bundle exec rake test_sqlite3 /Users/oscardelben/code/rails/activesupport/lib/active_support/core_ext/hash/keys.rb:70:in `block in assert_valid_keys': Unknown key: extend (ArgumentError) This is because some models used by tests are using the extend option which now seems deprecated. Should related tests be removed/migrated to not use these options anymore? I don't see mentions in the Changelog and documentation, but if this is the right direction I'd volunteer to update the code and docs. -- Oscar Del Ben -- 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. -- http://jonathanleighton.com/ -- 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] Errors running tests on master (d08fee3f284e6)
You need to do a bundle update On 14/07/12 02:36, kytrinyx wrote: I'm getting some `rake aborted` messages when running the tests on master. Specifically: https://gist.github.com/3108716 (there are more of them). I'm using 1.9.3-p194 Am I missing something? Can these safely be ignored? Cheers, Katrina -- 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/-/47REIjpgZRUJ. 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. -- http://jonathanleighton.com/ -- 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] Support for views on activerecord
One thing that I have recently found myself desiring is the ability to augment schema.rb with snippets of SQL. For example, I use Postgres, and need to declare some case-insensitive indexes. This is not currently possible using Rails directly. I don't want to switch to use the SQL schema dump format, because that's highly dependent on the database version. E.g. I am using Postgres 9, and another developer is using 8.4. We will probably end up overwriting each other's schema.sql files if we went this route. But it would be nice to have, say, a db/schema_extra.sql where we could manually place additional stuff like our case-insensitive indexes or whatever. Or views... -- http://jonathanleighton.com/ -- 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] Allow to use Proc on :order option of associations
There has been discussion about putting a new syntax into Rails 4 that
more closely resembles scopes. Example:
has_many :comments, - { where(deleted: false).order(:created_at) }
This would solve the problem of eager evaluation because it's contained
in a lambda.
I'll be looking into this when I get around to it.
On 03/05/12 19:28, Gabriel Sobrinho wrote:
Take a look (not my production code but reproduces the desired behavior):
``` ruby
class Post ActiveRecord::Base
attr_accessible :published_at, :name
has_and_belongs_to_many :categories, :order = lambda {
[Category.arel_table[:published_at].desc, Category.arel_table[:name]] }
end
```
``` ruby
class Category ActiveRecord::Base
attr_accessible :published_at, :name
has_and_belongs_to_many :posts, :order = lambda {
[Post.arel_table[:published_at].desc, Post.arel_table[:name]] }
end
```
``` ruby
Category.first.posts
# = TypeError: Cannot visit Proc
```
``` ruby
Post.first.categories
# = TypeError: Cannot visit Proc
```
The problem happens when we have a cross reference between two models
and need to use arel due to difference on quote of columns.
Sounds reasonable?
Reference: https://github.com/rails/rails/issues/6146
--
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/-/I5NDxR9PCvgJ.
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.
--
http://jonathanleighton.com/
--
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] ActiveRecord conditions: Symbol or String
On 20/04/12 12:21, Dmytrii Nagirniak wrote: Hi, A quick question: in the query `Company.where(:status = :active)`, is it OK to use the symbol (:active) as a value in the query? It definitely works with no issues at all. I'm not sure I'd consider it a public stable API, but if it works, go wild :). So it is not a public API and the symbols were not supposed to be used this way? RIght? It's not really good Ruby style. See http://blog.hasmanythrough.com/2008/4/19/symbols-are-not-pretty-strings However I think we'd probably have to add specific code to make it *not* work, so it will probably continue to work in the future. But I wouldn't recommend doing it. -- http://jonathanleighton.com/ -- 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] A truthy tempest in a teapot
On 26/03/12 02:13, Michael Koziarski wrote: In the absence of a particular bug which this difference causes, one not caused by a theoretical C programmer who writes != 0, then the entire discussion has already consumed more time than is justified by such a minor distinction. This. -- http://jonathanleighton.com/ -- 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] Proposal: api_compatibility config setting
TL;DR - should we add a config.api_compatibility to make the upgrade path for behavioural changes more straightforward? --- When we want to change or remove a user-facing feature, we add a deprecation to provide an upgrade path. Sometimes we cannot detect how a user is using a certain feature. If we're simply removing a method, it's easy to add a deprecation to that method and get no false positives. But if we are changing a behaviour of a method, we don't know whether people are relying on the previous behaviour in their own code. An example of this is the recent change to :dependent = :restrict https://github.com/rails/rails/commit/336ff8a What generally happens in these cases is either: * a configuration option gets added to newly generated apps to differentiate them, or * the change doesn't get made because it is too much hassle I believe that the proliferation of config option that change *behaviour* is harmful. It means that your AR objects (for example) are no longer defined solely by the code in app/models/, but also by a bunch of stuff in config/. If you want to use that code outside of a full Rails environment, it will behave differently. We could add an API compatibility config option: config.api_compatibility = 3.1 On each release, a config.api_compatibility option with a value below the current version would trigger a deprecation warning. If config.api_compatibility is nil, we would assume the current version. Pros: * Makes deprecation easier. If we're changing behaviour, we can use the api_compatibility to differentiate between older and newer apps. * Removes the need for adding lots of config options for deprecation, replaces it with one. Cons: * It's all-or-nothing. When upgrading, the user has to basically note down all the deprecations they get, update the api_compatibility, then fix stuff. * It's another step the user has to take when upgrading (but they can delay it). * It's a bit crap for people using e.g. Active Record outside of a full Rails app, as unless they explicitly set the api_compatibility option they'll just get bumped to the latest api_compatibility immediately when they upgrade. I'm not sure what I think about this, but I'm leaning towards liking it as anything that makes the upgrade path for behavioural changes clearer and easier seems like a good thing. I'm also not sure what to do about adding this in. I really don't want to make config.api_compatibility == nil imply 4.0, because I think the compatibility should be the latest unless explicitly specified otherwise. Thoughts welcome. -- http://jonathanleighton.com/ -- 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] Proposal: api_compatibility config setting
On 09/03/12 14:22, Steve Klabnik wrote: Rails should just follow SemVer instead. Assuming Rails did follow SemVer, are you suggesting that we would then just change/remove features between major versions without a deprecation path?! I think people would probably write more 'Rails sucks' articles if we did that. -- http://jonathanleighton.com/ -- 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] Proposal: api_compatibility config setting
On 09/03/12 15:56, Steve Klabnik wrote: Rails 3.3: scaffolding considered deprecated. Add deprecation warnings to all scaffolding stuff. Rilas 3.4: yep, still deprecated Rails 4.0: scaffolding removed. This example does not demonstrate the problem I am trying to solve. The problem is when behaviour changes, not when stuff gets removed. Suppose rails has a #lol method. Currently #lol return lol. We want to make it return omg. How do we know whether a user is relying on the current return value of lol, in order to give them a deprecation warning? -- http://jonathanleighton.com/ -- 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] Proposal: api_compatibility config setting
On 09/03/12 18:05, Steve Klabnik wrote: This is not backwards compatible. Therefore, a major version should be increased when it changes. I feel like this is going round in circles a bit, but... Introducing backwards incompatible changes without an upgrade path is not something that Rails currently does. I guess you are saying that you think Rails should just do that, coupled with adopting SemVer. Which is fair enough. Personally I think this would lead to people become more, not less, frustrated with the upgrade process though. Which would not be good, IMO. Hence I was trying to explore alternatives. -- http://jonathanleighton.com/ -- 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] Pull request: fix SQL generation bug in Postgres / Oracle
On 27/12/11 14:32, Matt jones wrote:
https://github.com/rails/rails/pull/4082
I've commented on the PR.
On a related note, the current mechanism for handling 'reorder' seems
pretty strange; what's the design motivation behind keeping the values
passed to reorder separate from order?
The reason is so that we can handle eagerly defined scopes correctly.
For example, consider:
class Post AR::Base
scope :by_bla, reorder('bla')
end
At the time the scope is defined, it is effectively:
class Post AR::Base
def self.by_bla
Post.reorder('bla')
end
end
If we 'collapsed' the order values at this point, when we later do, e.g.
Post.order('foo').by_bla
We are effectively doing:
Post.order('foo').merge Post.reorder('bla')
= Post.order('foo').merge Post.scoped
= Post.order('foo')
The 'foo' order would not be replaced because at the execution time we
don't have the information to know that 'by_bla' is supposed to trigger
a reordering.
The root problem is that we allow eagerly evaluated scopes to be defined
at all. Personally I dislike 'scope' and would rather that we just told
people to define their own class methods (which of course only get
evaluated when they are actually used). Others like the brevity of the
single line 'scope' syntax.
For Rails 4 I would like to discuss making use of the new lambda syntax
as a compromise, e.g.
scope :by_bla, - { reorder('bla') }
As a side-effect of that
implementation, this code:
SomeModel.order('foo ASC').reorder('bar DESC').order('baz ASC')
does not (as might be expected) sort the returned record by baz - the
reorder overrides all previous *and* subsequent orders.
I think this is a bug.
--
http://jonathanleighton.com/
--
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] Fixing the CHANGELOG
On Sat, 2011-11-19 at 20:55 -0800, Aaron Patterson wrote: No, you don't know for sure when you'll backport. But when you do, you don't have to change master as well. So when you backport, you create a new change in 3-1-stable, containing a) the fix and b) a CHANGELOG entry for 3-1-stable. This means that your merge is no longer just a cherry-pick. That's true, though I wouldn't find that a big problem as you often have to resolve conflicts during c-p's anyway. When it gets reverted in the 3-1-stable, your changelog entry was in the backport commit, so that gets reverted too. So if you revert on 3-1-stable, then do you need to add a changelog entry to master? If it was changelog worthy for 3-1-stable, surely it should be changelog worthy on master. No: bug fixes are only changelog-worthy on minor releases (i.e. 3-1-stable), not major releases (master). And feature additions should only be going into master, so would be changelogged there. -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
[Rails-core] [ANN] Rails 3.1.3
Rails 3.1.3 has been released. This release mainly contains fixes for regressions that popped up in 3.1.2. ## CHANGES ## Action Pack: * Downgrade sprockets to ~ 2.0.3. Using 2.1.0 caused regressions. * Fix using `translate` helper with a html translation which uses the `:count` option for pluralization. *Jon Leighton* Active Record: * Perf fix: If we're deleting all records in an association, don't add a IN(..) clause to the query. *GH 3672* *Jon Leighton* * Fix bug with referencing other mysql databases in set_table_name. *GH 3690* * Fix performance bug with mysql databases on a server with lots of other databses. *GH 3678* *Christos Zisopoulos and Kenny J* Railties: * New apps should be generated with a sass-rails dependency of 3.1.5, not 3.1.5.rc.2 As ever, you can see a full list of changes on Github: * https://github.com/rails/rails/compare/v3.1.2...v3.1.3 -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Fixing the CHANGELOG
On Thu, 2011-11-17 at 14:50 -0800, Aaron Patterson wrote: On Thu, Nov 17, 2011 at 10:30:13PM +, Jon Leighton wrote: Jon fixes a bug in master. It's a minor thing and not hugely relevant to the 3.2.0 release, so there is no changelog entry. SCENE 3 Jon backports the fix to 3-1-stable. It's more relevant there as it will feature in the forthcoming point release. So the changelog is updated: You can't for sure know that you'll backport from master to 3-1-stable. Also, if you do port to 3-1-stable and someone reverts, now your changelog entry is lost. I think this suffers exactly the same problems I mentioned in the original post. No, you don't know for sure when you'll backport. But when you do, you don't have to change master as well. So when you backport, you create a new change in 3-1-stable, containing a) the fix and b) a CHANGELOG entry for 3-1-stable. When it gets reverted in the 3-1-stable, your changelog entry was in the backport commit, so that gets reverted too. Maybe I am misunderstanding the problem? -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Fixing the CHANGELOG
On Thu, 2011-11-17 at 21:14 -0700, Jeremy Kemper wrote: 2b) Kill the CHANGELOG and use NEWS-style meaningful release notes instead. https://github.com/ruby/ruby/blob/trunk/NEWS https://github.com/ruby/ruby/blob/ruby_1_9_3/NEWS https://github.com/ruby/ruby/blob/ruby_1_8_7/NEWS This is sort-of what I was suggesting with my suggestion that stable branches are allowed to have different CHANGELOG contents from the master branch. -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
[Rails-core] Git tag for 3.1.2 release
Unfortunately I accidentally pushed an incorrect v3.1.2 tag yesterday. I immediately recognised that it was wrong, so quickly deleted it and pushed the correct tag. I thought that this would not be a problem for anyone who was not pulling the rails repository at that exact moment. It turns out I was wrong. If you have a rails repository clone that existed before the 3.1.2 release, in order to get the v3.1.2 tag into your repository, you will need to do: git fetch origin tag v3.1.2 I am very sorry for the inconvenience. -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Fixing the CHANGELOG
On Thu, 2011-11-17 at 10:25 -0800, Aaron Patterson wrote: Anyway, these are my thoughts. Input is definitely welcome, but I really think this is something we need to change. I'm definitely not keen on option 2. Option 1 I could live with, though I'd like to still keep the Markdown format. Another alternative is to actually just keep the stable release changelogs in the stable branch. So changelog entries between 3.1.0 and 3.1.1 would only exist in the 3-1-stable branch. Then we wouldn't have to fuss about keep master in sync. -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Fixing the CHANGELOG
On Thu, 2011-11-17 at 14:15 -0800, Aaron Patterson wrote: On Thu, Nov 17, 2011 at 07:05:34PM +, Jon Leighton wrote: On Thu, 2011-11-17 at 10:25 -0800, Aaron Patterson wrote: Anyway, these are my thoughts. Input is definitely welcome, but I really think this is something we need to change. I'm definitely not keen on option 2. Option 1 I could live with, though I'd like to still keep the Markdown format. Another alternative is to actually just keep the stable release changelogs in the stable branch. So changelog entries between 3.1.0 and 3.1.1 would only exist in the 3-1-stable branch. Then we wouldn't have to fuss about keep master in sync. I don't understand this solution. You're proposing no changelog on master? Not exactly. Best explained by example. SCENE 1 master: = ## 3.2.0 ## * Bla bla ## 3.1.0 ## * Bla bla = 3-1-stable: = ## 3.1.1 ## * Bla bla ## 3.1.0 ## * Bla bla = SCENE 2 Jon fixes a bug in master. It's a minor thing and not hugely relevant to the 3.2.0 release, so there is no changelog entry. SCENE 3 Jon backports the fix to 3-1-stable. It's more relevant there as it will feature in the forthcoming point release. So the changelog is updated: 3-1-stable: = ## 3.1.2 ## * Jon fixed a bug ## 3.1.1 ## * Bla bla ## 3.1.0 ## * Bla bla = Crucially, the 3.1.2 section does not need to be synchronised with master, just as the 3.2.0 section in master does not need to be synchronised with 3-1-stable. -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
[Rails-core] [ANN] Rails 3.1.2
Hi everyone,
Rails 3.1.2 has been released. This is a patch-level release containing
bug fixes and an important security fix.
## Possible XSS vulnerability in the translate helper method in Ruby on
Rails ##
There is a vulnerability in the translate helper method which may allow
an attacker to insert arbitrary code into a page.
Versions Affected: 3.0.0 and later, 2.3.X in combination with the
rails_xss plugin
Not Affected: Pre-3.0.0 releases, without the rails_xss plugin, did
no automatic XSS escaping, so are not considered vulnerable
Fixed Versions:3.0.11, 3.1.2
Please see [the rubyonrails-security
posting](http://groups.google.com/group/rubyonrails-security/browse_thread/thread/2b61d70fb73c7cc5)
and the changelog item below, for more details.
## CHANGES ##
Action Mailer:
* No changes
Action Pack:
* Fix XSS security vulnerability in the `translate` helper method.
When using interpolation
in combination with HTML-safe translations, the interpolated input
would not get HTML
escaped. *GH 3664*
Before:
translate('foo_html', :something = 'script') # =
...script...
After:
translate('foo_html', :something = 'script') # =
...lt;scriptgt;...
*Sergey Nartimov*
* Upgrade sprockets dependency to ~ 2.1.0
* Ensure that the format isn't applied twice to the cache key, else it
becomes impossible to target with expire_action.
*Christopher Meiklejohn*
* Swallow error when can't unmarshall object from session.
*Bruno Zanchet*
* Implement a workaround for a bug in ruby-1.9.3p0 where an error
would be raised while attempting to convert a template from one encoding
to another.
Please see http://redmine.ruby-lang.org/issues/5564 for details of
the bug.
The workaround is to load all conversions into memory ahead of time,
and will only happen if the ruby version is *exactly* 1.9.3p0. The hope
is obviously that the underlying problem will be resolved in the next
patchlevel release of 1.9.3.
*Jon Leighton*
* Ensure users upgrading from 3.0.x to 3.1.x will properly upgrade
their flash object in session (issues #3298 and #2509)
Active Model:
* No changes
Active Record:
* Fix problem with prepared statements and PostgreSQL when multiple
schemas are used.
*GH #3232*
*Juan M. Cuello*
* Fix bug with PostgreSQLAdapter#indexes. When the search path has
multiple schemas, spaces
were not being stripped from the schema names after the first.
*Sean Kirby*
* Preserve SELECT columns on the COUNT for finder_sql when possible.
*GH 3503*
*Justin Mazzi*
* Reset prepared statement cache when schema changes impact statement
results. *GH 3335*
*Aaron Patterson*
* Postgres: Do not attempt to deallocate a statement if the connection
is no longer active.
*Ian Leitch*
* Prevent QueryCache leaking database connections. *GH 3243*
*Mark J. Titorenko*
* Fix bug where building the conditions of a nested through
association could potentially
modify the conditions of the through and/or source association. If
you have experienced
bugs with conditions appearing in the wrong queries when using
nested through associations,
this probably solves your problems. *GH #3271*
*Jon Leighton*
* If a record is removed from a has_many :through, all of the join
records relating to that
record should also be removed from the through association's target.
*Jon Leighton*
* Fix adding multiple instances of the same record to a
has_many :through. *GH #3425*
*Jon Leighton*
* Fix creating records in a through association with a polymorphic
source type. *GH #3247*
*Jon Leighton*
* MySQL: use the information_schema than the describe command when we
look for a primary key. *GH #3440*
*Kenny J*
Active Resource:
* No changes
Active Support:
* No changes
Railties:
* Engines: don't blow up if db/seeds.rb is missing.
*Jeremy Kemper*
* `rails new foo --skip-test-unit` should not add the `:test` task to
the rake default task.
*GH 2564*
*José Valim*
As ever, you can see a full list of commits between the versions on
Github:
* https://github.com/rails/rails/compare/v3.1.1...v3.1.2
--
http://jonathanleighton.com/
signature.asc
Description: This is a digitally signed message part
[Rails-core] [ANN] Rails 3.0.11
Hi everyone,
Rails 3.0.11 has been released. This is a patch-level release containing
bug fixes and an important security fix.
## Possible XSS vulnerability in the translate helper method in Ruby on
Rails ##
There is a vulnerability in the translate helper method which may allow
an attacker to insert arbitrary code into a page.
Versions Affected: 3.0.0 and later, 2.3.X in combination with the
rails_xss plugin
Not Affected: Pre-3.0.0 releases, without the rails_xss plugin, did
no automatic XSS escaping, so are not considered vulnerable
Fixed Versions:3.0.11, 3.1.2
Please see [the rubyonrails-security
posting](http://groups.google.com/group/rubyonrails-security/browse_thread/thread/2b61d70fb73c7cc5)
and the changelog item below, for more details.
## CHANGES ##
Action Mailer:
* No changes
Action Pack:
* Fix XSS security vulnerability in the `translate` helper method. When
using interpolation
in combination with HTML-safe translations, the interpolated input
would not get HTML
escaped. *GH 3664*
Before:
translate('foo_html', :something = 'script') # =
...script...
After:
translate('foo_html', :something = 'script') # =
...lt;scriptgt;...
*Sergey Nartimov*
* Implement a workaround for a bug in ruby-1.9.3p0 where an error would
be
raised while attempting to convert a template from one encoding to
another.
Please see http://redmine.ruby-lang.org/issues/5564 for details of the
bug.
The workaround is to load all conversions into memory ahead of time,
and will
only happen if the ruby version is exactly 1.9.3p0. The hope is
obviously
that the underlying problem will be resolved in the next patchlevel
release
of 1.9.3.
* Fix assert_select_email to work on multipart and non-multipart emails
as the method stopped working correctly in Rails 3.x due to changes in
the new mail gem.
* Fix url_for when passed a hash to prevent additional options
(eg. :host, :protocol) from being added to the hash after calling it.
Active Model:
* No changes
Active Record:
* Exceptions from database adapters should not lose their backtrace.
* Backport ActiveRecord::Persistence#touch should not use
default_scope (GH #1519)
* Psych errors with poor yaml formatting are proxied. Fixes GH #2645 and
GH #2731
* Fix ActiveRecord#exists? when passsed a nil value
Active Resource:
* No changes
Active Support:
* No changes
Railties:
* Updated Prototype UJS to lastest version fixing multiples errors in IE
[Guillermo Iguaran]
As ever, you can see a full list of commits between the versions on
Github:
* https://github.com/rails/rails/compare/v3.0.10...v3.0.11
--
http://jonathanleighton.com/
signature.asc
Description: This is a digitally signed message part
Re: [Rails-core] Why do we have release candidates for patch releases?
I think the fact that I messed up rc1 is testament to the fact that RCs are a good idea ;) But in general, doing releases is a big hassle. Therefore, I would prefer to encounter this hassle on my own schedule, not in the middle of the night when I've just messed up a 'real' release and am racing against the clock to push out a fixed one. On Tue, 2011-11-15 at 13:13 -0800, Yehuda Katz wrote: Indeed. Advocating that we go back to what we did before is a big mistake. Releasing actual gems is the best way to make sure that people know about the impending release and have an opportunity to try it out and discover mistakes. In fact, the RC releases we have done *have* discovered mistakes. I don't want to build a process around the assumption of no mistakes. Yehuda Katz (ph) 718.877.1325 On Tue, Nov 15, 2011 at 7:26 AM, Jeremy Kemper jeremykem...@gmail.com wrote: On Tue, Nov 15, 2011 at 6:36 AM, Mislav mislav.maroh...@gmail.com wrote: Rails 3.1.2.rc2 just got released. Around the time of the 3.1.1 release, there was also a relatively evolved release process including announcements and release candidates. Why? Standardizing the process makes it easier to manage frequent releases. Pushing a candidate is part of making that process robust and repeatable. In other words, bugfix releases are cheap. Why waste time with release candidates when we can just get 3.1.2 right away? Then, every fix that would otherwise be made between 3.1.2.rc2-3.1.2 can just be released as 3.1.3. The candidates are to avoid release screwups, not to capture every last possible bug. (3.1.2.rc1, for example.) I love the spirit behind doing point releases like crazy and recovering quickly from issues with new point releases. But our experience shows that actually leads to *less frequent* releases. -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
[Rails-core] [ANN] Rails 3.1.2.rc2
Hi everyone, Rails 3.1.2.rc2 has been released. Dont ask about rc1! Please give it a try, but first read the important note below. If there are no release blockers, then I will be releasing the final version some time after 16:00 UTC on 17th November. ## IMPORTANT NOTE FOR RC TESTERS ## Rails 3.1.2 will depend on sprockets 2.1. The current stable version of sass-rails (3.1.4) depends on sprockets 2.0. To solve this problem, the current sass-rails release candidate removes its explicit dependency on sprockets, because sass-rails depends on actionpack which already depends on sprockets, so the version should be specified there. So to test this RC, you need to change your sass-rails dependency to: gem 'sass-rails', '~ 3.1.5.rc.2' When Rails 3.1.2 final is released, the final version of sass-rails 3.1.5 will also be released, so people with '~ 3.1.4' in their Gemfile will not have to do anything as Bundler will resolve the dependency itself. ## CHANGES ## Our changelogs are now in lovely Markdown format, which means you can read them all nicely formatted on Github! Here are the links: Action Mailer: * No changes Action Pack: * https://github.com/rails/rails/blob/3-1-2/actionpack/CHANGELOG.md Active Model: * No changes Active Record: * https://github.com/rails/rails/blob/3-1-2/activerecord/CHANGELOG.md Active Resource: * No changes Active Support: * No changes Railties: * https://github.com/rails/rails/blob/3-1-2/railties/CHANGELOG.md As ever, you can see a full list of commits between the versions on Github: * https://github.com/rails/rails/compare/v3.1.1...v3.1.2.rc2 And you can see the issues we haven't closed: * https://github.com/rails/rails/issues?sort=createddirection=descstate=openpage=1milestone=8 Cheers, Jon -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] All saved objects kept until the end of the tests
Hi Will, On Mon, 2011-10-03 at 17:18 +1300, Will Bryant wrote: One of the odd things that's blocking one big app I work on from moving up to Rails 3.0 or 3.1 is that with these versions whenever an object is saved, a reference to it is retained until the end of the enclosing transaction block, so that its state (new_record?, etc.) can be rolled back if the transaction is rolled back. There are several ways we can fix this What about adding a :consistent option when opening a transaction? E.g. # Rolls back record state if the transaction fails transaction do ... end # Doesn't roll back record state / keep references transaction(:consistent = false) do ... end Then, we could make the transaction around test runs be non-consistent? Jon -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Rails 3.1, has_many relationship and new records problem
On Thu, 2011-09-22 at 07:12 -0700, Daro wrote: If I have to change ALL my relationships with .all, I'm in a big trouble... am I missing something? Thank you very much. I can confirm what you have described: https://gist.github.com/1248588 In 3.0 there were inconsistencies between calling 'new' and 'build' on an association. I consider this a bug. In 3.1 the inconsistencies are tidied up, resulting in the behaviour you describe. If you want to issue a COUNT query to the db, use #count rather than #size. Cheers -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Noob Rails patcher - problems running the sqlite3 tests...
On Sun, 2011-09-25 at 04:10 -0700, kimptoc wrote: But this fails with undefined method `transform' for false:FalseClass (NoMethodError), see below. You should have a file test/config.yml which contains DB config for the various DBs you can run against. It doesn't exist by default, but *should* be copied from test/config.example.yml the first time you try to run the tests. So, could you check that it exists and that its contents are sane? -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] patch acceptance
Which specific PRs are you referring to? Generally if PRs are straightforward bug fixes etc they get merged pretty quickly. But when people suggest features or submit PRs that are not straightforwardly mergeable** they can linger unfortunately. One thing you can do to help yourself if to make it really clear that you have thought about all the possible problems already, e.g. * Get a friend to review the code * Give detailed explanation in the PR about the problem and the solution, to demonstrate that you've looked into it thoroughly * Make sure the tests are really thorough As a committer, I often find it quite hard to find time to work on 'the stuff I wanna work on' as whenever I sit down there is already a backlog of bugs and pull requests to deal with. So please bear with us basically :) But Github does seem better than Lighthouse IMO. Numerous pull requests do get merged daily. ** Reasons why a PR may not be straightforwardly mergeable: * Requires the merger to spend a non-trivial amount of time wrapping their head around the issue before feeling confident to accept the PR * Poor code quality * Suggests feature that may or may not be a good idea. Requires thought and discussion. On Tue, 2011-09-06 at 13:30 -0500, Andrew Kaspick wrote: I've had some patches (pull requests) ready in github for a while now and I haven't seen much action on them yet. Are there some specific steps that need to be taken other than just submitting a pull request? I noticed some patches have tags associated with them, but I don't know how you add these or if they are even necessary. When using lighthouse, patches seemed to get accepted much faster, whereas with github, patches seem to sit and get little attention (so far). I realize core is busy, but the difference in response time between acceptance on lighthouse vs github leads me to believe it's because of steps I've failed to perform to get the process moving along. Any advice on what needs to be done after a pull request is submitted? -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Performance of delegate
I am going to just repost what I said in GH-2711...
TL;DR - I agree with you, but others need convincing.
--
@dasch I tried to change this recently, and subsequently reverted in
8ba491a[1]. See discussion in aa1d1e4[2].
As you say, we have to deal with writer methods to make this work. My
implementation dealt with this by backporting public_send for 1.8.
However, the backport needed some more work and in any case would have
had performance difficulties I think.
It would be possible to do a special case for writer methods, but they
wouldn't be able to deal with more than one argument, without a backport
of public_send. IMO it would be best to just not let delegate work with
writer methods + multiple args (it's a very very edge case).
But anyway, given the opposition to this change (see discussion in the
commit linked) and the various complications with implementing it, I
lost interest and reverted.
By all means feel free to try to persuade people and suggest an
implementation, but I am just letting you know that I've already been
down the road and gave up ;)
[1]
https://github.com/rails/rails/commit/8ba491acc31bf08cf63a83ea0a3c314c52cd020f
[2]
https://github.com/rails/rails/commit/aa1d1e4962ba218f34defd0e7f0b665c795eb12b
--
On Mon, 2011-08-29 at 03:59 -0700, Daniel Schierbeck wrote:
Hi guys,
I recently discussed the `delegate` method with @tenderlove in
connection with GitHub issue #2711. I wished to replace
a series of manual delegations (using method declarations) with a
single call to `delegate`. Mr. @tenderlove correctly
pointed out that this would incur a deterioration of performance.
The current implementation of `delegate` is basically this, sans all
the bells and whistles:
def delegate(target, method)
class_eval(-RUBY)
def #{method}(*args, block)
#{target}.__send__(:#{method}, *args, block)
end
RUBY
end
He also identified four run-time issues which hurt performance
(paraphrased):
1. Stack depth impacts GC time
2. Paying an extra method call `__send__`
3. `*args` contraction (we must build an array that is just GC'd)
4. Splatting the args back to the `__send__`
While I cannot currently find a way to improve 3 and 4, I believe we
can alleviate the problems caused by the increased
stack depth and the overhead of the extra method call. These problems
both arise due to the use of `__send__`. Eliminating
the call yields:
def delegate(target, method)
class_eval(-RUBY)
def #{method}(*args, block)
#{target}.#{method}(*args, block)
end
RUBY
end
I ran a benchmark of the different implementations (https://
gist.github.com/1178156) using MRI versions 1.8.7 and 1.9.2.
The method row is the baseline, i.e. a manual delegation using a
full method definition. I'd love to see more people run
the benchmark to see how the results stack up.
Using MRI 1.8.7:
user system totalreal
method 8.46 0.01 8.47 ( 8.477583)
old 12.96 0.01 12.97 ( 12.978188)
new 9.35 0.01 9.36 ( 9.365799)
Using MRI 1.9.2:
user system totalreal
method 4.34 0.00 4.34 ( 4.349549)
old 4.67 0.00 4.67 ( 4.664780)
new 4.48 0.00 4.48 ( 4.477026)
The new implementation is clearly faster than the old, especially on
1.8.7.
There are, however, two caveats to this new implementation:
1. Writer methods (those ending in =) fail spectacularly. This is
due to the fact that you cannot directly call such a
method with more than one argument, i.e. `foo.bar=(1, 2)` is not
syntactically valid, while `foo.__send__(:bar, 1, 2)`
is. This can be solved by defining the argument list differently
for such methods - which would also benefit performance!
2. The semantics of `delegate` are slightly changed: it is no longer
possible to delegate to private methods.
The second issue is something that should be discussed here. I'm
biased towards loose coupling, and therefore believe
calling private methods on another object is inherently evil. It
*will* be a problem with regards to backwards compatibility,
assuming people actually use `delegate` for such a nefarious purpose.
I hope people will be interested in discussing this topic, as I think
`delegate` is an important part of the plumbing of
Rails, and deserves all the optimization we can muster. This is
especially true when we seize to use it internally because
it is too slow.
Cheers,
Daniel Schierbeck (@dasch)
--
http://jonathanleighton.com/
signature.asc
Description: This is a digitally signed message part
Re: [Rails-core] Re: Performance of delegate
On Mon, 2011-08-29 at 04:18 -0700, Daniel Schierbeck wrote: @jonleighton thanks for chiming in. I really believe that the basic constructs provided by ActiveSupport should uphold the rules of OOP - if you need to delegate to a private method nothing is stopping you from going the manual route. I seem to have fixed the performance issues, although I completely removed the ability to delegate to private methods, rather than deprecating it like you did. I've created a pull request so that the changes are more apparent: https://github.com/rails/rails/pull/2733 I removed the ability in master, and deprecated it in 3-1-stable. If we make this change, we do need to give people an upgrade path, so there does need to be a deprecation before the change is actually made. One feature of your implementation is that the following will not work: class Foo delegate :foo=, :to = :bar end foo.send(:foo=, 1, 2) # = will do 'foo.bar.foo = 1', not 'foo.bar.send(:foo=, 1, 2)' I think this is reasonable because this is a quite esoteric usage of a writer method. However, we should raise ArgumentError if there are multiple arguments in this case, and again we would need to provide a deprecation. I think checking args.length for writer methods should be performant enough for the deprecation. Then, in the future implementation, we could just define writer methods with no splat, so Ruby would take care of raising the ArgumentError. Jon -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Re: Performance of delegate
On Mon, 2011-08-29 at 14:16 +0200, Daniel Schierbeck wrote:
@Jon: I could change the implementation to check `args.length` and
raise ArgumentError if the result is greater than 1. But wouldn't it
suffice to simply define the writer methods with only one argument?
Yes, that's what I meant.
We need a patch against 3-1-stable that:
* Calls @target.foo, rescues NoMethodError, tries @target.__send__(:foo)
and if that works, shows a deprecation warning. (The reason for this
implementation is that there should be no performance hit in the public
case.)
* Shows a deprecation warning if args.length 1
method_name.ends_with?('=')
Then, we need the patch against master to just define def foo=(bar) (no
splat), when method_name.ends_with?('=').
If the deprecation in 3-1-stable is too involved, we might need to think
about deprecating in 3.2 and removing in 3.3. But let's see the code
first. Also note that this deprecation won't get into 3.1.0, so it would
be a new deprecation in 3.1.1. (Some may object to this, but I think
it's acceptable personally.)
@Xavier: I think users perceive `delegate` as a shorthand for:
def foo
@target.foo
end
and not
def foo
@target.__send__(:foo)
end
so I actually believe the proposed semantics more closely resembles
the perception. That's just my point of view, of course.
Yes, this is my perspective as well. To me the POLS is that 'delegate'
is a macro for the former, which does not support non-public methods.
--
http://jonathanleighton.com/
signature.asc
Description: This is a digitally signed message part
Re: [Rails-core] ActiveSupport::OrderedHash disappears?
If you're on 1.9 there is no slowdown with using OrderedHash vs Hash, as OrderedHash basically just inherits from Hash and does nothing else. https://github.com/rails/rails/blob/master/activesupport/lib/active_support/ordered_hash.rb#L51 On Thu, 2011-07-14 at 22:05 -0400, Prem Sichanugrist wrote: If your target deployment is Ruby 1.9, you *should* use Hash that come with Ruby. It's guaranteed to be sorted, and it doesn't have the same overhead that AS::OrderedHash has. Do you know that AS::OrderedHash is an array within array, and it's very slow? Hash in 1.9 is written in C, and doesn't suffer the same slowness. - Prem On Jul 14, 2011, at 9:37 PM, Andrew Kaspick wrote: Why don't you want to rely on it? It's documented behaviour, so you can totally rely on it. On Thu, Jul 14, 2011 at 5:47 PM, Alexey alexey.mura...@gmail.com wrote: Hello, i have asked this question here: https://www.ruby-forum.com/topic/2140803, but maybe you can answer quickly. Is ActiveSupport::OrderedHash going to be maintained in Rails? Its API page disappeared. I do not want to rely on Hash's being ordered in Ruby 1.9 (mainly because it is not called OrderedHash). Thank you, Alexey. -- 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/-/FsZLFviGct0J. 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. -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Setting primary key value manually
I tried using non-integer keys a while back and eventually gave up. I half got it working, but there were numerous issues. This is something I'd really like to get working properly in 3.2. On Fri, 2011-07-08 at 12:02 -0700, Aaron Patterson wrote: On Fri, Jul 08, 2011 at 10:37:50AM -0700, Luis Correa d'Almeida wrote: In ActiveRecord 3.1.0.rc4, setting the id manually no longer works - the assignment seems to be ignored. Is this expected behavior? Seems to break BC create_table :posts, :id = false do |t| t.string :id, :limit = 36, :primary = true, :null = false t.string :title end @post = Post.new @post.id = abc123 @post.id = nil @post.save! = Fails because id is nil/null (obviously) Thoughts? If it worked in 3.0.9, but doesn't work in 3.1.0, please file a ticket (along with a test case if you can). In this case, I think it's likely this behavior was undefined (had no test case). At the very least we should add a test case that specs the behavior for this. -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Rails 3.1 RC4 default_scope and count
Please could you file this as an issue on Github, with a full example of
the models you are using?
Jon
On Sun, 2011-06-12 at 14:52 -0700, jgelo wrote:
I've run into an issue in Rails 3.1 RC4 where the count query is
failing because of a default_scope. The scope has an include and a
condition on the included association but count is dropping the
include. Here's what it looks like -
default_scope where('campaigns.inactive = ?',
false).order('funds.name').includes(:campaigns)
Rails 3.1 RC4 -
ruby-1.9.2-p180 :001 Fund.count
[2011-06-12 14:35:43 | WARN | n/a | named_scope.rb:175:in
`valid_scope_name?']
Creating scope :all. Overwriting existing method Fund.all.
[2011-06-12 14:35:43 | DEBUG | n/a | log_subscriber.rb:105:in `debug']
(0.4ms) SELECT COUNT(*) FROM funds WHERE (campaigns.inactive = 'f')
ActiveRecord::StatementInvalid: PGError: ERROR: missing FROM-clause
entry for table campaigns
LINE 1: SELECT COUNT(*) FROM funds WHERE (campaigns.inactive =
'f...
Rails 3.0.8 -
ruby-1.9.2-p180 :001 Fund.count
= 1
SQL (43.8ms) SELECT COUNT(DISTINCT funds.id) FROM funds LEFT
OUTER JOIN campaigns ON campaigns.fund_id = funds.id WHERE
(campaigns.inactive = 'f')
--
http://jonathanleighton.com/
signature.asc
Description: This is a digitally signed message part
Configuring AR test connections (was: Re: [Rails-core] [ANN] Rails 3.1.0.rc4 has been released!)
Hi Ken, The change was done because we had a failing CI, which was failing because each different branch was using the same database and conflicts ensued (also this meant we could not build branches in parallel). So the aim of the change was actually to make things *more* configurable and so allow us to use different dbs for each branch. To this end the test/config.yml file was added to allow you to configure database connections. This file is .gitignore'd. There is a test/config.example.yml file in the repo. The first time you run the tests, the example config will be copied if the config file doesn't exist already. So, you should be able to set up your test connections for SQL server within test/config.yml. Is this all you need? Perhaps you need to be able to run a bit of code before the tests, to require some files or add some workarounds or something? If so, possibly we could add a simple hook mechanism. I.e. if ARTest.prepare_connection_sqlserver is defined, and the DB connection in use is 'sqlserver' (this is set by a ARCONN env var or by the default_connection key in test/config.yml), then ARTest.prepare_connection_sqlserver gets run at the beginning of ARTest.connect. TL;DR If the current system isn't configurable enough for your use case, give me the gorey details and we can sort something out. Thanks! Jon On Thu, 2011-06-09 at 23:11 -0400, Ken Collins wrote: OK, just reporting back that defining my own support/config.rb and return a simple hash of data for ARTest.config works just great - Ken On Jun 9, 2011, at 10:08 PM, Ken Collins wrote: I just noticed that the long overdue and inevitable reorganization of the test directories for ActiveRecord have changed since the first release candidate. Has this directory structure and new config/connection setup been done in such a way that allows adapters maintained outside of rails core to easily hook in? Case in point, the SQL Server adapter has always defined a rake test task that uses test libs and files in a rather clever way that set's the load path to leverage the AR test suite along side of a rich set of our own. I suspect other adapter projects have done this too. So I am reading thru the changes and without much evidence I'm a little pessimistic that I'll be able to hook things up correctly from an outside in approach. For instance, the helper will require 'config' and that file in turn will set some various XYZ_ROOT constants. The problem is if I create a config.rb in my test root so that AR's helper loads mine and then I set my (for example) TEST_ROOT to my local directory, all the things in the load path for using things like FIXTURES_ROOT would not work. If you wondering why I would set something like TEST_ROOT to my local directory, it seems that this would be needed for support/config.rb to load my connection information. So it looks like I'm in a catch-22. I suppose I could redefine a support/config.rb in my load path forcing that one to be used and just keep it slim and focused to just use ARTest.confg with my loaded configurations. Is this the suggested way? I'll let you know what I find out as I am trying to get my tests running again now. I ask for just a little bit of time while I cope with the changes. BTW, really excited about 3.1 releasing. The SQL Server adapter eats up the prepared statement support. Our speed benefits are just as high as PostgreSQL's - Thanks, Ken On Jun 9, 2011, at 7:09 PM, Aaron Patterson wrote: I've pushed a 3.1.0.rc4. Please test it against your application against this release candidate and report any regressions to the [rails core mailing list](http://groups.google.com/group/rubyonrails-core). I would like to hear your feedback, good or bad. Especially if it's good. 3 3 In two weeks, if there are no show stopping issues I will release the final version. If we do find regressions, I will publish another release candidate and we'll put another two weeks on the clock. However, I will not wait two weeks between release candidates. I want to get the final done as quickly as possible, so I'll try to release RCs as quickly as possible. ## CHANGES Here are some of the major changes to the RC branch: * `escape_javascript` safebuffer fixes * `json_escape` safebuffer fixes * RDoc / ruby-debug conflict fixes. * arel_table is cached unless the table_name changes For an exaustive list, please check out the commits on [github](https://github.com/rails/rails/compare/v3.1.0.rc3...v3.1.0.rc4). 3 3 3 -- Aaron Patterson http://tenderlovemaking.com/ -- 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
Re: [Rails-core] Rails 3.0.6 ETA?
Hiya, I chatted to Aaron and he said it's okay to say that 3.0.6rc1 is planned to be released March 28th, and then the final release on March 31st. There is a general plan afoot to have a monthly stable release cycle. Obviously, plans can change and dates can slip and people must not complain if the universe does not pan out exactly as set out above :) Jon On Tue, 2011-03-22 at 11:17 -0700, Jason King wrote: All production apps should be moved to 3.0.5 as soon as possible. You won't lose any significant time doing the 3.0.5 - 3.0.6 later. On Tue, Mar 22, 2011 at 5:53 AM, Vít Ondruch v.ondr...@gmail.com wrote: Hello, Is there some Rails 3.0.6 ETA? I am asking because there are some security holes in Rails 3.0.3, which are currently available in Fedora 15. So is it right time to update Rails to 3.0.5 or is it worth of waiting for 3.0.6? Vit -- 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. -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Re: default_scope, named scopes and lambda arguments
Adam,
Thanks for your thoughtful response. I have re-read your previous email,
and this email, and thought about it some more.
I have changed my mind. I now agree that the best thing to do would be
to have 'scope' take blocks.
Essentially what we're getting at is that scopes should be lazily
evaluated. There may be some hackery we can apply to have laziness
without 'scope' taking a block, but ultimately it will always be
hackery. The only way to make the laziness completely transparent to the
users of the API would be to make it obvious, i.e. by requiring them to
use a block. Having a block makes it instantly clear that the evaluation
does not happen immediately.
My initial reticence was essentially because I think scope :foo
{ where(:bla) } is ugly (it's also syntactically invalid without
parentheses actually). But in reality, I think if this were the syntax
then I would just declare all my scopes as:
scope :foo do
where(:bla)
end
This actually appeals to me additionally because it makes it look more
like a method. Scope are essentially just hyped-up class methods which
get cached when they are accessed through associations.
So, in short, I approve of this proposal.
One question though. Why do we need:
default_scope do
lambda { where(:bla} }
end
Why not just:
default_scope do
where(:bla)
end
?
Also, have you thought about how to make the transition from the current
syntax? My proposal would be to deprecate the non-block syntax in 3.1
and explain to people why it might not give them what they want, but to
not actually remove it until 3.2. I think we should allow time to
upgrade as this is a feature that basically everybody uses.
Jon
On Sun, 2011-03-06 at 14:43 +0100, Adam Wróbel wrote:
Thanks for your comment. I think your proposal could solve the issue from
example 4 - joining named scopes that are lambdas, but it wouldn't help with
default scope being applied to the relation passed as argument to subsequent
`default_scope` or `scope` calls.
But here are some considerations anyway. You couldn't just store lambdas on
the Relation, because the order of operations matter.
class Post ActiveRecord::Base
scope :localized, lambda { where( :locale = Locales.current ) }
end
# those two are different
Post.localized.where(:locale = :en)
Post.where(:locale = :en).localized
You could store a queue of previously applied Relation and lambda objects
though. Of course two consecutive Relation objects could be merged the
traditional way.
Although it would look transparent to the user and rails apps wouldn't
require any special migration to 3.1, the AR code would become significantly
more complex.
By making every named and default scope a lambda you just need to change two
AR methods that prepare the Relation just before putting it on the current
scope stack. On the other hand by introducing a relation-lambdas queue you
have to make some methods aware of this queue. You mentioned `to_a`, but this
could be postponed until `build_arel` which is called by `to_a` and similar.
Then there are info methods like `where_clauses` which are used by AR, but
also by some gems I presume. Those would need to flatten the whole queue to
return proper results.
Furthermore there are methods like `except` and `reverse_order` which would
need to be reimplemented as actual elements on the queue. Currently `except`
just drops some commands from the Relation object and `reverse_order` just
changes the order clauses ASC and DESC properties. If we were to put those
methods on top of lambas queue, you would have to remember the requested
operation and apply it only after the lambda would be evaluated.
I'm worried about AR maintainability here. And the performance hit would
probably be bigger than one additional proc evaluation every time named scope
is used.
All this and it wouldn't solve the default scope issue unless you tried to
mark the elements on the queue as coming from default scope and dropping them
from queues coming from named scopes.
Adam
On Mar 5, 2011, at 20:06 , Jon Leighton wrote:
Hey Adam,
Thanks for looking into this, it definitely seems like there are some
fundamental design issues that are surfacing here.
I agree with the thrust of your proposal, but it would be good to
investigate whether it is possible to implement this lazy evaluation
without changing the syntax to have blocks all over the place.
For example, perhaps it would be possible to store the lambda-scopes on
the actual ActiveRecord::Relation object and only evaluate the lambdas
at the very last minute (i.e. when to_a is called).
I haven't thought about this particularly long and hard so there may be
other issues with this approach...
Cheers,
Jon
On Fri, 2011-03-04 at 11:37 -0800, Adam Wróbel wrote:
To solve the default scope problem it's enough to execute the blocks
Re: [Rails-core] Re: default_scope, named scopes and lambda arguments
Hey Adam,
Thanks for looking into this, it definitely seems like there are some
fundamental design issues that are surfacing here.
I agree with the thrust of your proposal, but it would be good to
investigate whether it is possible to implement this lazy evaluation
without changing the syntax to have blocks all over the place.
For example, perhaps it would be possible to store the lambda-scopes on
the actual ActiveRecord::Relation object and only evaluate the lambdas
at the very last minute (i.e. when to_a is called).
I haven't thought about this particularly long and hard so there may be
other issues with this approach...
Cheers,
Jon
On Fri, 2011-03-04 at 11:37 -0800, Adam Wróbel wrote:
To solve the default scope problem it's enough to execute the blocks
at the `unscoped` level, but if we also want to solve the issue shown
in example 4 we need to delay block execution until default_scope or
named scopes are used. Then of course returning lambdas from the block
is unnecessary and a proper code would look a bit cleaner than what I
have shown above:
# example 3
class Post ActiveRecord::Base
default_scope { where( :locale = Locales.current ) }
scope :valid { where( :valid = true ) }
end
And:
# example 5
class Product ActiveRecord::Base
scope :not_deleted { where(products.deleted_at is NULL) }
scope :available do |*on|
where(products.available_on = ?, on.first ||
Time.zone.now )
end
scope :active { not_deleted.available }
end
Adam
On Mar 4, 6:15 pm, Adam Wróbel a...@fluxinc.ca wrote:
This is a rather broad topic covering a few related issues. Please
bear with me while I elaborate.
Rails 3.0 supports lambda named scopes and there has been a request to
add support for lambda default_scopes in 3.1. With a help of a few
folks and under an eye of Aaron Patterson some work has been made
which is documented in this rather long ticket on
lighthouse:https://rails.lighthouseapp.com/projects/8994/tickets/1812-default_sc...
Unfortunately we've stumbled upon problems which are impossible to
overcome with simple patches. With the rails 3 new where(), order(),
limit(), etc. functions ActiveRecord::Relation objects are created and
merged dynamically and always in the context of the current scope.
Consider those examples:
# example 1
class Post ActiveRecord::Base
default_scope lambda { where( :locale = Locales.current ) }
scope :valid, where( :valid = true )
end
The `where` function will be called before the call to `scope` and it
will return a new ActiveRecord::Relation object that will be saved as
the named scope. Unfortunately that relation will be created within
the currently active scope, which for calls at the AR class level is
the default scope. Read: the default scope will be evaluated during
the call to `scope` and it's resulting conditions will be merged
with :valid scope conditions.
Then whenever a user will call `Post.valid` two things will happen:
- first, default scope will be evaluated again and will produce a
Relation object with new, proper conditions
- second, this Relation will be merged with Relation saved in :valid
scope, which contains conditions from the call to `default_scope` at
the time of :valid scope declaration.
As a result of this merge the current conditions will be overwritten
by that
outdated data.
This also means that later you can't run :valid at the `unscoped`
level. Like `Post.unscoped.valid` - the resulting relation will
contain conditions taken from the `default_scope`.
Note that this would not happen if the programmer decided to declare
the scope like this:
# example 2
class Post ActiveRecord::Base
default_scope lambda { where( :locale = Locales.current ) }
scope :valid, unscoped.where( :valid = true ) # notice
'unscoped'
end
In this case the :valid scope does not contain conditions from the
default scope. But this is not transparent to the coder. It's not The
Rails Way if you have to remember to use `unscoped` if you've used
lambda before.
I had some ideas for dirty hacks that would work around this problem.
One of which ended up as a pull request on
github:https://github.com/rails/rails/pull/169
In that patch I modified ActiveRecord::Relation to contain a mirror
relation without data from the default scope, I called that mirror
`without_default`. Each time a relation is merged with another so are
their `without_default` counterparts. The relation returned from
default scope has it's `without_default` cleared, so it's where the
branch point comes from. Then when I save a relation as new named
scope, I use it's `without_default` version.
It's terrible, messy. I know. It gets the job done for this one issue,
but it's a bad design.
What I have suggested to Aaron and others is
Re: [Rails-core] Re: will thi multibyte issue be fixed in 2.3.11 ?
Hi, The 2.3 branch has reached end of line, so new releases will only be made in that branch if the problem is omg critical. Cheers, Jon On Fri, 2011-02-25 at 21:08 -0800, Enrico wrote: I guess I was too lazy to try for myself... I just updated my app to 2.3.11 and I still needed to apply these 2 patches: https://rails.lighthouseapp.com/projects/8994/tickets/4808-textarea-input-silently-truncated-in-238 and this gist https://gist.github.com/838489 which addresses the original issue I was asking about: https://rails.lighthouseapp.com/projects/8994/tickets/2188-i18n-fails-with-multibyte-strings-in-ruby-19-similar-to-2038 Any plans to consider these for a 2.3.12 ? On Feb 25, 1:05 pm, Enrico enrico.brune...@gmail.com wrote: I would like to know if this will be fixed in 2.3.11 : https://rails.lighthouseapp.com/projects/8994/tickets/2188-i18n-fails... -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Associations are not consistent in honoring :dependent = destroy (db is fill with orphaned objects)
The behaviour of deletion/destruction on associations can be confusing, and there is a lack of documentation. I have done some work recently to improve consistency across the different types of associations, and improve the documentation too. So the current situation in master is that: * delete/destroy on an association removes the link, and not necessarily the actual associated records. For has_many the link is the records itself, so there is no distinction. For has_many :through and has_and_belongs_to_many, only the join/through record is removed as this is the link. * Doing a.association.delete(*records) will perform the deletion according to the :dependent option. Using the :dependent option basically causes a before_destroy callback to call a.association.delete_all. With has_many :through, if you want to remove the associated records also, then you should probably add the :dependent option to the source association in your join model. Jon On Sat, 2011-02-19 at 20:09 -0800, Solas wrote: if a model A has_many :bee, :through = :c, :dependent = :destroy ... a.destroy properly cleans up all the bee's ... however. If one does this: a.bees = [] c records are destroyed... bees are untouched. This is misleading to me, as: while I can understand semantics that just the array has been modified... something like :dependent = :destroy should be invariant (the dependents should be destroyed, under all cases where... the object is a dependent) I am new to this list, so: how does one file a ticket? -Solas -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Associations are not consistent in honoring :dependent = destroy (db is fill with orphaned objects)
Hey, On Sun, 2011-02-20 at 23:00 +0100, Xavier Noria wrote: Please note that the documentation clearly says the :dependent option is ignored altogether for hmt. It is better to work on the join model. I recently implemented the :dependent option for hmt, so it will be supported in Rails 3.1. But I agree, except for a few specific case (e.g. tags through taggables) it is better to work with the join model direct. Jon -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] CSRF Protection Bypass in Ruby on Rails - I don't get it ...
Hi, A description of this exploit has been posted here: http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html [I presume any bad guys will have seen that post, so didn't see why not to point people to it on this mailing list.] Jon On Thu, 2011-02-10 at 10:06 +1300, Michael Koziarski wrote: 1. Where is the complete Advisory? The Impact section is very unclear. Looking at the comment in the 2.3 patch mentions Flash animations and Java applets - does the whole thing deserve a bit more explaining? We've been deliberately vague in the description of the exploit so as not to provide ready-made exploit kits to attack other frameworks and rails applications which haven't been upgraded. We've been contacted since by a browser vendor and a few other frameworks requesting details. I'm sure the full details of how this can be exploited are already available in some circles but for now we're not going to make that job any easier. I don't think providing any more details here will help anyone, it affects your users and is easily exploitable. 2. Lines 40-48 in the 2.3 patch changes the CSRF protection to only allow get requests and requests with the correct form authenticity token through - is this not going to break stateless web service and ActiveResource post requests that does not maintain state on the client side? - line 228 in the 2.3 patch tests that xml requests should be validated for authenticity token. This is going to break quite a few things. Should Rails by default (still) support authenticated stateless requests (for the sake of web services)? Or should we handle this by overriding handle_unverified_request (line 31 patch 2.3)? What am I missing? You don't need to override anything. The behaviour of handle_unverified_request is to reset the session, this should not in any way affect your API clients (or anything else stateless). However if you've already overridden verify_request_token in your app you'll need to remove that. API requests will indeed cause handle_unverified_request to be called, however it won't affect them at all as they won't notice that the session cookie has 'changed' as they didn't use it in the first place. If you have API requests which *do* rely on the session, then you're fucked as that's a CSRF request by definition. -- Cheers Koz -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] CSRF protection in rails 2.3.11
Hi there, As you've identified, the difference between 2.3.10 and 2.3.11, and between 3.0.3 and 3.0.4, in how they handle invalid csrf tokens is that the former will raise ActionController::InvalidAuthenticityToken, but the latter will reset the session. What we are trying to protect against is the following situation: * Alice is logged in to Facebook * Alice visits badsite.com * Mallory, who owns badsite.com has added some code into the page which makes a request to facebook.com and posts on Alice's wall. * Alice visits badsite.com and without her intending it to be, a comment is posted on her wall With the current CSRF protection, the following will happen: * Alice is logged in to Facebook * Alice visits badsite.com * Mallory, who owns badsite.com has added some code into the page which makes a request to facebook.com and posts on Alice's wall. * Alice visits badsite.com and without her intending it to be, a request is made to post on her wall * Facebook detects that there is no CSRF token associated with the request, and so logs her out by resetting the session * Then, based on the authorisation rules within the application, Facebook denies to post on the wall, because the user is not logged in With the old CSRF protection, the following will happen: * Alice is logged in to Facebook * Alice visits badsite.com * Mallory, who owns badsite.com has added some code into the page which makes a request to facebook.com and posts on Alice's wall. * Alice visits badsite.com and without her intending it to be, a request is made to post on her wall * Facebook detects that there is no CSRF token associated with the request and so refuses to serve the request in any way (returns 500) * So nothing gets posted on the wall The point is, they are different but both have the effect of preventing the wall post. If for some reason you specifically want an exception to be raised in this situation, you can customise handle_unverified_request, but it doesn't compromise the aim of the CSRF protection to no raise an exception, so long as the request is not allowed to go through as authenticated by the existing session. Jon On Fri, 2011-02-11 at 11:28 -0800, Mathijs wrote: Hi all, I think CSFR protection broke in rails 2.3.11. As in: it's turned off now. I tried this in rails 2.3.10 and in 2.3.11 and 2.3.11 seems broken. rails csrftest cd csrftest script/generate scaffold post title:string rake db:migrate now I visit /posts/new in my browser, use firebug to delete or change the authenticity token, and submit the form. rails 2.3.11: all fine, new post saved rails 2.3.10: ActionController::InvalidAuthenticityToken I checked ApplicationController to see if it still contained protect_from_forgery, which is the case. I read the announcement for the csrf changes in 2.3.11 and they talk about overriding handle_unverified_request for special cases where there are other ways for authenticating a user. In this simple case I demonstrated though, there is no concept of a user or logging in (or a session), so the default action of resetting the session is not very useful. In my opinion, CSRF protection is about verifying a request. It doesn't have anything to do with users/sessions/authentication. By default, a faulty request (unprotected/wrong token) should not reach the normal controller action code at all, so the main action to take when a non-verified request comes in, is to have the before_filter chain halt. nothing more, nothing less. Extra stuff (like destroying a session) is up to the user (or nice to leave in as a default). So I think the behavior in 2.3.11 is just wrong, because in the example I gave, the forms just get submitted and stuff gets persisted to the database. It's not clear from the announcement at all that you should now make sure the filter chain halts, or that you must protect your actions by something that's stored in the session (because that's all that gets done when a faulty request hits). Maybe I'm just doing something wrong here, please let me know. Mathijs -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Why does Rails not reset the association when the id is changed?
On Mon, 2011-02-07 at 14:28 +0100, Rainer Frey wrote: On Mon, Feb 7, 2011 at 11:58 AM, Xavier Noria f...@hashref.com wrote: On Sun, Feb 6, 2011 at 2:10 PM, Rainer Frey frey.rai...@gmail.com wrote: Unfortunately the Rails Guide on Active Record Validation and Callbacks says (Section 3.9): If you want to be sure that an association is present, you’ll need to test whether the foreign key used to map the association is present, and not the associated object itself. Maybe the guide needs to be updated. Yeah, I think the wording is unfortunate. Certainly you can't be sure the association is present by checking that the FK attribute is present. Rather, this topic deserves a warning in my view. Something in the line that if you check whether the FK attribute is present then you *don't know* whether it is valid. You can decide to take the risk, that's up to you, but the reader should be warned. But this thread seems to suggest one should simply validate the association attribute instead. Is that not sufficient then? I'd say validating the association attribute would be the best practice in 3.1, but it may result in an extra query to the database to fetch the associated record, if it's not loaded or if it's stale. If users wish to avoid that overhead, they can check the FK, but should be aware that this does not guarantee the associated record actually exists. -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Why does Rails not reset the association when the id is changed?
Hey,
On Mon, 2011-02-07 at 15:22 +0100, Xavier Noria wrote:
On Mon, Feb 7, 2011 at 2:28 PM, Rainer Frey frey.rai...@gmail.com wrote:
But this thread seems to suggest one should simply validate the
association attribute instead. Is that not sufficient then?
You can't still be sure the association is valid, because the
associated object is cached if previously fetched, and the FK can be
changed directly:
This does work 'properly' on edge, due to the stale-checking mechanism.
I just tried it. Voila:
$ rails c
Loading development environment (Rails 3.1.0.beta)
ruby-1.9.2-p136 :001 post = Post.create
= #Post id: 1
ruby-1.9.2-p136 :002 comment = post.comments.create
= #Comment id: 1, post_id: 1
ruby-1.9.2-p136 :003 comment.post_id = -1
= -1
ruby-1.9.2-p136 :004 comment.save
= false
ruby-1.9.2-p136 :005 comment.errors
= {:post=[can't be blank]}
ruby-1.9.2-p136 :006 comment.post
= nil
Jon
--
http://jonathanleighton.com/
signature.asc
Description: This is a digitally signed message part
Re: [Rails-core] Why does Rails not reset the association when the id is changed?
Hey, In edge rails there is a mechanism for checking whether the loaded association target is stale - so if you do record.foo_id = x, then record.foo will load the target afresh. I'm not sure whether it necessarily works with validation like this, but hopefully it does. [I haven't tried.] Just to emphasise, this is new in edge - it is not in the 3-0-stable branch. Jon On Fri, 2011-02-04 at 15:39 -0500, Ernie Miller wrote: 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 class Child belongs_to :parent end I've always thought that validating the :parent (and not the foreign key) is the *more* correct thing to do ... but I don't understand why Rails does not reset the parent association when the parent_id is changed as demonstrated here, child = Child.find(..) child.parent_id = nil puts child.valid? # outputs false child = Child.find(..) child.parent child.parent_id = nil puts child.valid? # outputs true! Any thoughts? This is due to the way that association proxies lazy load their targets. In the first case, if you only loaded the child record, and modified the parent_id attribute, then you never load the parent object, because you never accessed the association proxy. In the latter case, you did access the association proxy, so the parent got loaded, but then you modified the parent_id, directly. I'd recommend that you be consistent -- if you're checking if the associated object exists, set the association to nil, instead of the id, and you shouldn't have a problem. -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] ActiveRecord suggestion: Object.in? to complement Enumerable.include?
Hey,
FWIW, there was a pull request for something similar fairly recently,
but it didn't really go anywhere:
https://github.com/rails/rails/pull/138
Jon
On Wed, 2011-01-26 at 20:38 +0300, Evgeniy Dolzhenko wrote:
That would be a useful addition, the method was in Facets library for
ages I think
https://github.com/rubyworks/facets/blame/master/lib/core/facets/kernel/in.rb
But I guess to get it into the ActiveSupport you would also need to have
(examples at least)
of using it throughout Rails code base.
Anyway, I'm +1 on it.
On 1/26/2011 8:29 PM, Brian Morearty wrote:
Hello,
This is a joint patch from rubyduo (at gmail) and myself. Some of the
following is extracted from our discussion on Lighthouse (https://
rails.lighthouseapp.com/projects/8994/tickets/6321-add-improved-
version-of-enumerableinclude). It was suggested we bring it up here to
try and garner some support for the contribution rather than let the
ticket languish in Lighthouse.
Sometimes you want to ask a question like
Is x 1 or 2?
Normally you write this as:
[1,2].include?(x)
which seems backwards to us.
We have created a patch to ActiveSupport, with tests, that allows you
instead to write:
x.in?([1,2])
Thanks to duck typing, this extension works with any type that
implements include?:
# Array
a = [1,2,3]
3.in?(a) # = true
4.in?(a) # = false
# Hash
h = { a = 100, b = 200 }
a.in?(h) # = true
z.in?(h) # = false
# String
lo.in?(hello)# = true
ol.in?(hello)# = false
?h.in?(hello) # = true
# Range
25.in?(1..50)# = true
75.in?(1..50)# = false
# Set
require 'set'
s = Set.new([1,2])
1.in?(s) # = true
3.in?(s) # = false
# Even Module
module A
end
class B
include A
end
class C B
end
A.in?(B) # = true
A.in?(C) # = true
A.in?(A) # = false
The patch is based on rubyduo's proposal and on my in_enumerable gem,
which has been in use since late 2009 and is solid. The patch includes
a number of tests.
In Lighthouse we also discussed a couple of other options but decided
against them. Here's a quick summary, and you can read more about
them in the ticket:
1. Rubyduo's original suggestion was that in? would take a list of
parameters instead of a single parameter. We agreed in the end that a
single parameter is better because of the added flexibility of working
with any type that implements include?.
2. We discussed having the best of both worlds: allowing a single
parameter or a list of parameters. But in this case, that would lead
to ambiguity and hard-to-track-down bugs so we agreed it's not the
right course.
I would be happy to deprecate in_enumerable if this change is put into
ActiveSupport. See the following if you want more info on
in_enumerable:
- Original announcement:
http://ilikestuffblog.com/2009/12/24/now-you-can-use-obj-inarray-instead-of-array-includeobj/
- Source code: https://github.com/BMorearty/in_enumerable
Thanks so much. Any ideas or feedback would be appreciated.
Brian Morearty and rubyduo
P.S. In an odd bit of timing, rubyduo and I didn't know each other
before but the stars aligned and we had the same idea *on the same
day* to suggest this patch to ActiveRecord.
--
http://jonathanleighton.com/
signature.asc
Description: This is a digitally signed message part
Re: [Rails-core] Should includes with general association name work?
This looks like a bug to me. You should try a few things:
* Can you repro on master?
* What about doing where('referrals.employer_representative' = ...) -
does that make a difference?
* Try doing the query manually (i.e. Users.includes(..).where(...)) - I
doubt the scope is the problem but good to rule things out.
(BTW the bug is probably in ActiveRecord::Relation, not arel. Also,
specifying the query in a different order won't make a difference since
the query will only be built when it's needed, not incrementally.)
Cheers
On Tue, 2011-01-11 at 12:05 -0500, Rick DeNatale wrote:
Hi, I'm wondering if this is an arel bug or should be a new feature.
I've got a model with the following:
has_many :recommendations, :class_name = Referral,
:foreign_key = :candidate_id
scope :recommended_to, lambda {|er|
joins(:recommendations).where(:referrals = {:employer_representative
= er})}
This works and generates the right inner join.
puts User.recommended_to(er).to_sql
users INNER JOIN referrals ON referrals.candidate_id =
users.id WHERE (referrals.employer_representative = '6')
But if I change joins to includes in the scope, I get:
puts User.recommended_to(er).to_sql
SELECT users.* FROM users WHERE
(referrals.employer_representative = '6')
Which won't work since it needs the join.
I know that the old :include option only generated a join clause if
there was also a condition which required it, and since the includes
method doesn't know that it kind of makes sense. I also tried
chaining the includes after the where in hopes that then include WOULD
know, but it didn't make a difference.
Is there, or should there, be a way in such a case to force includes
to generate the join as well as instantiating the associated records?
--
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
--
http://jonathanleighton.com/
signature.asc
Description: This is a digitally signed message part
Re: [Rails-core] has_many :dependent = :destroy and association callbacks
Hiya, I am working on refactoring this section of the code at the moment actually, and this problem will be fixed when I'm done. Cheers On Tue, 2010-12-28 at 08:27 -0800, Robert Pankowecki wrote: Today I noticed that calling object.collection.destroy_all leads to calling association callbacks like ex. :before_remove but object.destroy does not call those callbacks when configured with :dependent = :destroy option. You can find that hbtm uses collection.clear which under the hoods calls collection.destroy_all however has_many uses the metod configure_dependency_for_has_many to setup the hooks ( https://github.com/rails/rails/blob/master/activerecord/lib/active_record/associations.rb#L1000 ) which iterates over the collection and sends destroy() to every object (https://github.com/rails/rails/blob/master/activerecord/lib/ active_record/associations.rb#L1625) I think it could be a good thing to make has_many behave more like hbtm and just use collection.destroy_all . This way also the association callbacks would get called. Also probably the optimization fix with counter_method could probably be move to the call in destroy_all. -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
[Rails-core] has_many :through deletion and destruction
Hi all, I am going to write a fairly long email about deletion and destruction in has_many :through associations, and then make some proposals. Sorry for the length, but I think it's currently a mess which we need to get sorted. Please do read it :) ### Issues ### -- * The :dependent option is not supported, and the default behaviour for delete (a delete_all operation) is different to has_many (a nullify operation) * delete and destroy operate on different records (explained further below) * delete, and destroy since 3.0, raise an exception unless the source association is a belongs_to * Counter caches and :touch fields are not updated correctly on deletion ### History ### --- Consider the following: class Post AR::Base has_many :taggings has_many :tags, :through = :taggings end In 2.3, the behaviour was thus: * post.tags.delete(tag) would not affect the tag at all, but it would delete the relevant Tagging record, thus detaching the tag from the post * post.tags.destroy(tag) would delete the tag record, but would not affect the tagging record at all, thus leaving invalid records lying around Ticket #2251 was created about this, which contains quite a bit of fairly confusing debate: http://bit.ly/fBpCfM The solution proposed in #2251 was to make destroy behave more like delete, and a patch was submitted which causes post.tags.destroy(tag) to delete both the tag AND the tagging. This lead to a complaint that destroy had ceased to work in some cases where it had previously work. Specifically, because destroy now involved the join record, it didn't work unless the source association on the join record was a belongs_to. Due to the complaint, Michael Koziarski reverted the change in 2-3-stable, but left it in master (which went on to become 3-0-stable) pending further discussion. There was some further discussion, but it eventually petered out without any action, so we now have a situation where that change has crept into 3-0-stable without proper agreement. Some of that further discussion centred around the assumptions that are made by has_many :through about your join records. In the above example, you might expect post.tags.delete(tag) to delete the tagging, on the basis that you don't want orphaned records just lying around. However, this is an assumption that Tagging exists purely to link Post to Tag, and does not have any independent purpose. Here's another example: class Post AR::Base has_many :comments has_many :comment_authors, :through = :comments, :source = :author end class Comment AR::Base belongs_to :author end Suppose we can have anonymous comments, which have no associated author. Now, if we follow the same assumptions, post.comments_authors.delete(author) should also delete the associated comment. But we can clearly see that this assumption could be wrong if what we actually want to achieve is to make all of a given author's comments on a given post anonymous. I basically think that the lack of support for the :dependent option has lead to assumptions being built into has_many :through, because people have lacked the ability to be explicit about what they want. ### Proposal ### Here is my proposal: * If the :dependent option is implemented in an analogous way to the implementation for regular has_many, it will provide enough power to be completely explicit about what should be done in a given situation, and therefore we can stop making (potentially incorrect) assumptions * delete and destroy should only ever operate on the same records, as implied by the documentation of them in AssociationCollection [reminder: at the moment delete operates on the join record, but destroy operates on the join record and the associated record] * Therefore, has_many :through should never specifically delete join records during a delete or destroy operation (but it may do given the right configuration of :dependent options on models) To illustrate why this will solve things, I'll return to the examples given. Assuming my proposal is implemented, the tags example could be coded like so: class Post AR::Base has_many :taggings, :dependent = :destroy has_many :tags, :through = :taggings end class Tagging AR::Base belongs_to :post belongs_to :tag end class Tag AR::Base has_many :taggings, :dependent = :destroy has_many :posts, :through = :taggings end Now consider post.tags.delete(tag). In the absence, of a :dependent option, we should fall back to the default of nullification, so no records are actually deleted. The tag_id on the tagging is nullified. However, if we did post.tags.destroy(tag), the tag itself would of course be destroyed. But because :dependent is set on Tag#taggings, the associated tagging would *also* be destroyed automatically, as desired. So no orphaned records. But the option would also be open to add a :dependent option to Post#tags, in which case post.tags.delete(tag) would act in the same way
[Rails-core] has_many :through - deletion and destruction
Hi all, I am going to write a fairly long email about deletion and destruction in has_many :through associations, and then make some proposals. Sorry for the length, but I think it's currently a mess which we need to get sorted. Please do read it :) ### Issues ### -- * The :dependent option is not supported, and the default behaviour for delete (a delete_all operation) is different to has_many (a nullify operation) * delete and destroy operate on different records (explained further below) * delete, and destroy since 3.0, raise an exception unless the source association is a belongs_to * Counter caches and :touch fields are not updated correctly on deletion ### History ### --- Consider the following: class Post AR::Base has_many :taggings has_many :tags, :through = :taggings end In 2.3, the behaviour was thus: * post.tags.delete(tag) would not affect the tag at all, but it would delete the relevant Tagging record, thus detaching the tag from the post * post.tags.destroy(tag) would delete the tag record, but would not affect the tagging record at all, thus leaving invalid records lying around Ticket #2251 was created about this, which contains quite a bit of fairly confusing debate: http://bit.ly/fBpCfM The solution proposed in #2251 was to make destroy behave more like delete, and a patch was submitted which causes post.tags.destroy(tag) to delete both the tag AND the tagging. This lead to a complaint that destroy had ceased to work in some cases where it had previously work. Specifically, because destroy now involved the join record, it didn't work unless the source association on the join record was a belongs_to. Due to the complaint, Michael Koziarski reverted the change in 2-3-stable, but left it in master (which went on to become 3-0-stable) pending further discussion. There was some further discussion, but it eventually petered out without any action, so we now have a situation where that change has crept into 3-0-stable without proper agreement. Some of that further discussion centred around the assumptions that are made by has_many :through about your join records. In the above example, you might expect post.tags.delete(tag) to delete the tagging, on the basis that you don't want orphaned records just lying around. However, this is an assumption that Tagging exists purely to link Post to Tag, and does not have any independent purpose. Here's another example: class Post AR::Base has_many :comments has_many :comment_authors, :through = :comments, :source = :author end class Comment AR::Base belongs_to :author end Suppose we can have anonymous comments, which have no associated author. Now, if we follow the same assumptions, post.comments_authors.delete(author) should also delete the associated comment. But we can clearly see that this assumption could be wrong if what we actually want to achieve is to make all of a given author's comments on a given post anonymous. I basically think that the lack of support for the :dependent option has lead to assumptions being built into has_many :through, because people have lacked the ability to be explicit about what they want. ### Proposal ### Here is my proposal: * If the :dependent option is implemented in an analogous way to the implementation for regular has_many, it will provide enough power to be completely explicit about what should be done in a given situation, and therefore we can stop making (potentially incorrect) assumptions * delete and destroy should only ever operate on the same records, as implied by the documentation of them in AssociationCollection [reminder: at the moment delete operates on the join record, but destroy operates on the join record and the associated record] * Therefore, has_many :through should never specifically delete join records during a delete or destroy operation (but it may do given the right configuration of :dependent options on models) To illustrate why this will solve things, I'll return to the examples given. Assuming my proposal is implemented, the tags example could be coded like so: class Post AR::Base has_many :taggings, :dependent = :destroy has_many :tags, :through = :taggings end class Tagging AR::Base belongs_to :post belongs_to :tag end class Tag AR::Base has_many :taggings, :dependent = :destroy has_many :posts, :through = :taggings end Now consider post.tags.delete(tag). In the absence, of a :dependent option, we should fall back to the default of nullification, so no records are actually deleted. The tag_id on the tagging is nullified. However, if we did post.tags.destroy(tag), the tag itself would of course be destroyed. But because :dependent is set on Tag#taggings, the associated tagging would *also* be destroyed automatically, as desired. So no orphaned records. But the option would also be open to add a :dependent option to Post#tags, in which case post.tags.delete(tag) would act in the same way
[Rails-core] Prevent a has_one association going :through a collection association
Hi all, Please see: https://rails.lighthouseapp.com/projects/8994/tickets/2912 There, I am proposing a patch which prevents a has_one association going :through a collection association. If you have comments please add them. Thanks, Jon -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
Re: [Rails-core] Re: Nested :through associations
Hi all, Jose has responded on the pull request: === Hey mate, thanks for the pull request. But could you please send this request to Rails mailing list and get feedback from more people? At first, I am -1 on this feature. Rails has_many :through, without being nested, already have a few limitations that I really would like to see fixed before adding more complexity. For example, in the case User has many groups through subscriptions, the following does not work: group = user.groups.build group.save As it does not save the associated object subscriptions. Calling .create() works as expected though. The lack of the ability to support a dependent option (like :destroy, :delete) for the associated record is also another limitation (currently we have dangling records). We can find others examples in LH. === I wanted to respond here to prevent the discussion being split over multiple places: I see the concern. Though we should be clear that nested through associations will only ever be read-only, as writing to them would not make any sense (not enough information to determine correct join records). What I would propose is that I do an audit of tickets on LH that are related to has many through. I suspect some of them will be solved by my patch (as it rewrites lots of HMT code). I could identify others which are still an issue. Then maybe we could identify which other tickets should be fixed before this nested patch goes in. I'm happy to look at other tickets as a stepping stone to getting this patch in. However it would be good if people could be up front and say now if there are general concerns with this patch in principle, or whether concerns are just around not introducing more bugs in HMT given the number of existing bugs. Hope that makes sense. Cheers, Jon On Mon, 2010-11-29 at 02:27 -0800, Jon Leighton wrote: The patch has now been verified on Lighthouse. I.e. 3 people have tested and +1ed it. I've done a pull request here: https://github.com/rails/rails/pull/121 I merged latest master over the weekend and will continue to merge as necessary to keep it up to date. Jon On Nov 29, 1:42 am, lardawge larda...@gmail.com wrote: Jon, I would make sure this currently merges into master and send a pull request on github with the lighthouse ticket in the comments... Need get more eyes on it. On Nov 17, 3:40 am, Jon Leighton j...@jonathanleighton.com wrote: Hi all, In October I worked on a patch for a long-requested feature: associations that can go :through anything, including other :through associations. The Lighthouse ticket is here:https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1152 I believe this is a robust, well-tested patch. I want to get it merged, but there has been very little response to the patch on Lighthouse. I should probably have posted on here before now - but here I am now anyway. Can anyone help verify/review this patch? Any suggestions about how best to get it accepted by the core team? Also, can somebody with the relevant permissions changes the status from incomplete to open please? I am actively maintaining the branch and merging in the latest master from time to time. I will also happily deal with any issues which arise as a result of this patch. Thanks, Jon Leighton --http://jonathanleighton.com/ signature.asc 1KViewDownload -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
[Rails-core] Re: Nested :through associations
The patch has now been verified on Lighthouse. I.e. 3 people have tested and +1ed it. I've done a pull request here: https://github.com/rails/rails/pull/121 I merged latest master over the weekend and will continue to merge as necessary to keep it up to date. Jon On Nov 29, 1:42 am, lardawge larda...@gmail.com wrote: Jon, I would make sure this currently merges into master and send a pull request on github with the lighthouse ticket in the comments... Need get more eyes on it. On Nov 17, 3:40 am, Jon Leighton j...@jonathanleighton.com wrote: Hi all, In October I worked on a patch for a long-requested feature: associations that can go :through anything, including other :through associations. The Lighthouse ticket is here:https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1152 I believe this is a robust, well-tested patch. I want to get it merged, but there has been very little response to the patch on Lighthouse. I should probably have posted on here before now - but here I am now anyway. Can anyone help verify/review this patch? Any suggestions about how best to get it accepted by the core team? Also, can somebody with the relevant permissions changes the status from incomplete to open please? I am actively maintaining the branch and merging in the latest master from time to time. I will also happily deal with any issues which arise as a result of this patch. Thanks, Jon Leighton --http://jonathanleighton.com/ signature.asc 1KViewDownload -- 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] Nested :through associations
Hi all, In October I worked on a patch for a long-requested feature: associations that can go :through anything, including other :through associations. The Lighthouse ticket is here: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1152 I believe this is a robust, well-tested patch. I want to get it merged, but there has been very little response to the patch on Lighthouse. I should probably have posted on here before now - but here I am now anyway. Can anyone help verify/review this patch? Any suggestions about how best to get it accepted by the core team? Also, can somebody with the relevant permissions changes the status from incomplete to open please? I am actively maintaining the branch and merging in the latest master from time to time. I will also happily deal with any issues which arise as a result of this patch. Thanks, Jon Leighton -- http://jonathanleighton.com/ signature.asc Description: This is a digitally signed message part
[Rails-core] Support for updating a belongs to association from the foreign key (without saving and reloading the record)
Hi all, I would like to solicit feedback for this ticket: http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/142-patch-belongs_to-association-not-updated-when-assigning-to-foreign-key. The reasoning is explained in the ticket so I won't repeat that here but I would like to hear any opinions on why this should or should not be applied. The latest patch (as of today) is available here: http://rails.lighthouseapp.com/attachments/44268/belongs_to_update_association_from_foreign_key.diff Cheers, Jon --~--~-~--~~~---~--~~ 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] Loading the schema for Active Record tests
Apologies if this is blatantly obvious and I am wasting your time - I'm quite an infrequent Rails contributor... Basically I am looking for an easy way to load the schema definitions from activerecord/test/schema into my databases. In the RUNNING_UNIT_TESTS file it says When you have the database online, you can import the fixture tables with the test/schema/*.sql files. This seems to be outdated as all the files in test/schema are now .rb schema files. I can't see a rake task to perform this - maybe there should be one? I'd be happy to create a patch to make this a bit easier for others in the future. Cheers, Jon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
