Re: [Rails-core] ActiveRecord connection pool management

2015-09-30 Thread Xavier Noria 
"it checks out a connection separately for each database action"

Transactions are per connection, how does that approach handle them?

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

[Rails-core] Proposal: Multiple Validation Contexts

2015-09-30 Thread Nam Chu Hoai 
Hey all,

Validations are a relatively obscure and not particularly well documented 
feature that do come in handy when using particularly complex models with 
complex lifecycles and states. Ideally, I'd use Concerns to dynamically add 
validations but that hasn't been proven fruitful. I was wondering what you 
guys and gals think of extending validation contexts to be an array, so 
that one could pass in multiple contexts?

Nam

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

Re: [Rails-core] Proposal: Multiple Validation Contexts

2015-09-30 Thread Kasper Timm Hansen 
Already on master: https://github.com/rails/rails/pull/21069.

Reported in This Week in Rails here: 
https://rails-weekly.ongoodbits.com/2015/09/11/performance-mysql-prepared-statements-and-more
 ;)

> Den 29. sep. 2015 kl. 20.17 skrev Nam Chu Hoai :
> 
> Hey all,
> 
> Validations are a relatively obscure and not particularly well documented 
> feature that do come in handy when using particularly complex models with 
> complex lifecycles and states. Ideally, I'd use Concerns to dynamically add 
> validations but that hasn't been proven fruitful. I was wondering what you 
> guys and gals think of extending validation contexts to be an array, so that 
> one could pass in multiple contexts?
> 
> Nam
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> .
> Visit this group at http://groups.google.com/group/rubyonrails-core 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

--
Kasper

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

Re: [Rails-core] ActiveRecord connection pool management

2015-09-30 Thread James Coleman 
Xavier,

As far as I know, Rails already doesn't wrap the entire request in a
transaction, so that shouldn't be an issue.

Unless what you're saying is that operations already wrapped in a
transaction block would be affected.

On Wed, Sep 30, 2015 at 1:29 PM, Xavier Noria  wrote:

> "it checks out a connection separately for each database action"
>
> Transactions are per connection, how does that approach handle them?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [Rails-core] Re: Adding Model#model_name

2015-09-30 Thread Carlos Ribeiro 
Sorry for replying an old post =(.
But, I am moving an app from Rails 4.1.x to Rails 4.2.4 and  I am with 
error wher I use  

ActiveModel::Erros.new(object) when the object it is not an activemodel. I 
am looking on the rails source code and the ActiveModel::Error has changed 
from 4.1.x to 4.2.4 
https://github.com/rails/rails/blob/v4.2.4/activemodel/lib/active_model/errors.rb#L412
 
with this PR. This method on the line 437 
(https://github.com/rails/rails/blob/v4.2.4/activemodel/lib/active_model/errors.rb#L437)
 
is trying to look for the method model_name from the instance, but in the 
version 4.1.x it looks from the class. It was changed on this commit: 
https://github.com/rails/rails/commit/6b0e834a194d112585f41deba0a40780d68e38c6.

 I know that I can fix it by creating a module that I can use on my class 
with this method using the ActiveModel::Naming. Am I wrong in use 
ActiveModel::Error without an activemodel? And the older way is not right 
in use the method from class?

Thanks so much, and sorry for opening an old topic again =/
Em segunda-feira, 23 de junho de 2014 21:29:38 UTC-3, Amiel Martin escreveu:
>
> Excellent start Yuki!
>
> I started working on this as well on Friday and came to pretty much the 
> same solution.
>
> I would have just left my changes in favor of Yuki's PR, but I think is 
> misses the point.
> The idea is for rails to stop calling x.class.model_name, and only call 
> x.model_name.
>
> I've started another PR making those changes: 
> https://github.com/rails/rails/pull/15889 
> 
>
> There's still two things to address:
>
>1. I've left a few REVIEW comments. I'm looking for feedback there, 
>but will remove them and rebase soon enough.
>2. I'm still working on a warning to address the issue that Andy 
>Jeffries brought up in this thread.
>I'm thinking it should just be a warning. I'm digging into it now; 
>does anyone know of an example of rails currently doing this?
>
>
> Thanks!
>
> -Amiel
>
>
> On Mon, Jun 23, 2014 at 6:42 AM, Yuki Nishijima  > wrote:
>
>> Pull request sent: https://github.com/rails/rails/pull/15871
>>
>>
>> On Fri, Jun 20, 2014 at 7:15 AM, DHH > > wrote:
>>
>>> I'm very much in favor of this as well. Please make it so. To address 
>>> Andy's concerns, we should have proper error messages if this is 
>>> overwriting an attribute of the same name. But it's too convenient not to 
>>> have.
>>>
>>>
>>> On Friday, May 30, 2014 8:11:53 PM UTC+2, Jeremy Friesen wrote:

 Following up on https://github.com/rails/rails/issues/15428, with 
 adjustments.

 Throughout the Rails code there are a few references to 
 `object.class.model_name`. Instead of always pushing this up to the class, 
 it makes sense to me that we ask the model for its model_name.

 This might obviate the need for the dubious 
 ActionController::ModelNaming#model_name_from_record_or_class,  
 https://github.com/rails/rails/blob/master/actionpack/
 lib/action_controller/model_naming.rb




 module ActionController
   module ModelNaming


 # Converts the given object to an ActiveModel compliant one.



 def convert_to_model(object)
   object.respond_to?(:to_model) ? object.to_model : object


 end

 def model_name_from_record_or_class(record_or_class)


   (record_or_class.is_a?(Class) ? record_or_class : 
 convert_to_model(record_or_class).class).model_name


 end
   end


 end


 Example:

 class Foo
   extend ActiveModel::Naming
   def model_name
 class.model_name
   endend
 Foo.respond_to?(:model_name)=> true
 Foo.new.respond_to?(:model_name)=> true
 Foo.model_name == Foo.new.model_name=> true

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

-- 
You received this message

Re: [Rails-core] ActiveRecord connection pool management

2015-09-30 Thread Michael Vigilante 

>
> On Thursday, 1 October 2015 03:30:55 UTC+10, Xavier Noria wrote:

>
> Transactions are per connection, how does that approach handle them?
>

>From what I can tell, ActiveRecord only provides one way to manually open a 
transaction, which is a `transaction do ... end` block; in this case, if 
the connection is checked out and in around `transaction`, it will still 
work OK; you'll have the same connection and the same transaction for 
everything within that block.

Aaron, I have no idea if I'll be able to work that out, but I'll give it a 
shot.

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

Re: [Rails-core] ActiveRecord connection pool management

2015-09-30 Thread Aaron Patterson 
On Mon, Sep 28, 2015 at 10:01:23PM -0700, Michael Vigilante wrote:
> OK, mock-up is here: 
> https://github.com/stranger-zedd/activerecord-connection-pool-tests

Ah, I see what you're saying now.  TBQH, as it really seems fine if we
internally do check connections in.  I just don't know how much of an
effort it will require.  I suspect there are maybe 1 or 2 places that
we would have to change to get the most benefit.  The main thing I worry
about is checking out a connection where we don't actually need to do
any database work (like getting the schema cache).

If you're interested in finding the places we need to fix, I'd be happy
to merge the patch! :)

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

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


pgp22VxXPfH3z.pgp
Description: PGP signature