Re: [Rails-core] When will Active Record be really Rails-independent? Concern about migrations

[ChuckE]

Hehe, quanto ao tradutor, não será certamente o problema ;) Obrigado pelo 
link, vou dar uma olhada então. 

On Wednesday, October 17, 2012 3:17:44 PM UTC+2, Gabriel Sobrinho wrote:
>
> ChuckE,
>
> The master application had the only objective to handle the migrations 
> that was shared between the client systems, the application was used just 
> to be able to run rake db:migrate.
>
> The client applications not even knew about that, they are all just 
> expecting the database to be ready all the time.
>
>
> Maybe your case will be more likely the Nando Vieira case here: 
> http://simplesideias.com.br/usando-modelos-activerecord-entre-projetos-diferentes(portuguese)
>
> I think will not be a problem to you understand the post if you use a 
> translator ;)
>
> On Tuesday, October 16, 2012 10:24:18 AM UTC-3, ChuckE wrote:
>>
>> Hey Gabriel,
>>
>> That sounds interesting, even though it is not a solution for my 
>> particular issue, because it's not all Rails application. So you have a 
>> master application and many slaves. Are the slaves "moving" the migrations 
>> to the master app, and then being executed there? and Are the rake tasks 
>> from the slave applications calling the same rake tasks in the master 
>> application scope? Are the migrations organized only in one place or are 
>> they spread across application but run in an orderly fashion timestamp-wise?
>>
>> On Tuesday, October 16, 2012 3:05:28 PM UTC+2, Gabriel Sobrinho wrote:
>>>
>>> ChuckE,
>>>
>>> It is not the best solution but some years ago I worked on a project 
>>> with that case, one shared database.
>>>
>>> To solve the problem of shared migrations, we created a rails 
>>> application just to run the shared migrations on the database.
>>>
>>> That required an extra step before each application deploy, deploy the 
>>> "shared" application first and after that deploy the "client" applications.
>>>
>>>
>>> I'm working on another project that required the same solution, a shared 
>>> database.
>>>
>>> Today is more easier because all applications are rails 3 applications, 
>>> so I created a gem called and did that: 
>>> http://pastie.org/private/jdxqeuwhu7kncx56aclppg
>>>
>>> Using that, you just run rake db:migrate on client applications and 
>>> everything works fine.
>>>
>>>
>>> You should be aware from clashing migration versions between client 
>>> applications because you won't be noticed about that.
>>>
>>> On Tuesday, October 16, 2012 9:43:49 AM UTC-3, ChuckE wrote:

 Hey Ryan,

 - I'm not working with multiple databases on one application, I'm 
 working with multiple applications (using different ruby frameworks, but 
 all using ActiveRecord) on one database. Actually I've worked already with 
 one Rails application on multiple databases, and with some configuration 
 over convention, it is possible. 
 - The migration tasks don't come with Rails, they come with 
 ActiveRecord. Rafael said that the rake tasks are only made available via 
 Railtie, hence they are only automagically usable in a Rails environment. 
 But they belong to ActiveRecord. My concern is only that these AR tasks 
 make use of Rails (and Engine, in this case) variables to make assumptions 
 about migrations directory and such, instead of making it part of the 
 ActiveRecord configuration. 

 On Monday, October 15, 2012 11:36:58 PM UTC+2, Ryan Bigg wrote:
>
> I think the answer here that Rafael gave is spot-on. The migration 
> tasks that come with Rails are designed with one database in mind. If 
> you're operating with multiple databases, then you should create your own 
> migration tasks that migrate your databases for you.
>
> On 16 October 2012 07:27, Jesse Wolgamott 
> wrote:
>
>> Installing extensions is not a requirement to get ActiveRecord 
>> migrations to work. It might help, but the code required to migrate is 
>> pretty straight forward. Rails makes a lot of assumptions about what you 
>> want to do with your databases, with different environments 
>> (dev/test/etc), 
>> seeding, or that you might have migrations in engines that you could run.
>>
>> I created a simple repo that uses AR without Rails: 
>> https://github.com/jwo/ActiveRecord-Without-Rails (postgres specific 
>> setup). And if you don't need to migrate, you can simply connect to an 
>> existing database: https://github.com/jwo/dbfu … Setup for these 
>> ruby only projects is minimal. You don't automagically get all the rake 
>> tasks that Rails gives you, but in simple ruby projects you might not 
>> need 
>> them.
>>
>> - jwo
>>
>>
>> On Monday, October 15, 2012 at 12:57 PM, ChuckE wrote:
>>
>> But that's the point: I think the rake tasks shouldn't be 
>> Rails-dependent. Since ActiveRecord is dependent from the migration it 
>> must 
>> run before it is deemed loadable, I think the

Re: [Rails-core] Suggestion: default values for models

[Gabriel Sobrinho]

That is a problem for me either.

I can't use before_save callback because I need to show the default value 
on forms.

So, I have a date field and the default value is today, but when user open 
the form, today must be on that field.


I'm setting this kind of default value on controller like that:

def new
  @payment = Payment.new
  @payment.date = Date.current
end

But this become a mess since I have "dynamic" default values in almost 
every model of my application.

On Wednesday, October 17, 2012 4:41:55 PM UTC-3, Zamith wrote:
>
> Isn't this just the same as having a before_save callback where you define 
> these default values?
>
> Also, what do you mean with "We can use db's default values but they are 
> evaluated during migrations"?
> On Oct 17, 2012, at 8:28 PM, Alexander Kurakin wrote:
>
> ROR doesn't realize functionality of setting default values for models. We 
> can use db's default values but they are evaluated during migrations. We 
> can't set default value i.e. Time.now. But there are completed gems that 
> realize this. I.e. default_value_for (
> https://github.com/FooBarWidget/default_value_for). Why not to merge it 
> in rails? Thanks.
>
> -- 
> 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/-/u1PNgYmkABUJ.
> To post to this group, send email to rubyonra...@googlegroups.com
> .
> To unsubscribe from this group, send email to 
> rubyonrails-co...@googlegroups.com .
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
> Cumprimentos,
> Luís Ferreira
>
>
>  
>

-- 
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/-/Q5Pjbb3Oow0J.
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] ActiveRecord: updating an association of an already persisted instance in memory without making the update persist right away. Is this possible?

[ChuckE]

Hi,

I have ClassA, which has many objects of ClassB. Let's say that the 
dependency of that relationship is of the destroy kind:

class ClassA < ActiveRecord::Base
has_many :class_bs, :dependency => :destroy
end
class ClassB < ActiveRecord::Base
belongs_to :class_a
end

Now let's say I already have a persisted instance of ClassA, and this 
instance has also associated persisted objects:

   a = ClassA.first
   a.persisted #=> true
   a.class_bs.length #=> >1
   a.class_bs,all?{|b|b.persisted?} #=> true

So now, I would like to replace my associated class_bs with a new 
collection of only one element, which is not persisted. I would like to 
keep this only in memory, until I save the parent (or its child, for all I 
care):

   new_bs = [ClassB.new]
   new_bs.all?{|b| b.new_record? } #=> true
   a.class_bs = new_bs
   a.class_bs.all?{|b| b.new_record?} #=> true
   a.save
   a.class_bs.all?{|b| b.new_record?} #=> false

Problem is, the way it works, step 4 will return "false" instead of true. 
That is, as soon as I assign something to an already persisted parent, the 
new associations are stored right away (unless they are invalid). This is 
something that I don't like, because I may want to associate a to another 
object x, and I want to validate everything before I persist the changes, 
but the way it works, as soon as I get to x, changes were already made. Is 
there a way to do this in AR? and still keep the dependency => destroy? 

Thanks in advance

-- 
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/-/EWRssQGCFw4J.
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] Re: Suggestion: render filters

[Nick Sutterer]

On Wednesday, September 5, 2012 3:53:50 PM UTC-3, Alexander Kurakin wrote:
>
> Will not be useful functionality similar 
> https://github.com/shell/rails3_before_render ? Something like 
> ActionController filters but not before action. Filters before render. See 
> also http://www.perfectline.ee/blog/ruby-on-rails-before-render-filter, 
> http://penkin.co.uk/rails3_before_render-plugin/. And don't you know gem 
> for this? Thanks.
>

I guess he wants some mechanism that hooks into the action processing 
workflow so you can declarativly define stuff (in the controller, like a 
filter) that is done with the model before it is passed to the rendering 
layer. Just guessing without following the links!

-- 
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/-/Jukh-LfT2hEJ.
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] Suggestion: default values for models

[Allen Madsen]

This is relevant:
http://stackoverflow.com/questions/328525/what-is-the-best-way-to-set-default-values-in-activerecord

They mention using after_initialize.

Allen Madsen
http://www.allenmadsen.com


On Thu, Oct 18, 2012 at 8:50 AM, Gabriel Sobrinho <
gabriel.sobri...@gmail.com> wrote:

> That is a problem for me either.
>
> I can't use before_save callback because I need to show the default value
> on forms.
>
> So, I have a date field and the default value is today, but when user open
> the form, today must be on that field.
>
>
> I'm setting this kind of default value on controller like that:
>
> def new
>   @payment = Payment.new
>   @payment.date = Date.current
> end
>
> But this become a mess since I have "dynamic" default values in almost
> every model of my application.
>
>
> On Wednesday, October 17, 2012 4:41:55 PM UTC-3, Zamith wrote:
>
>> Isn't this just the same as having a before_save callback where you
>> define these default values?
>>
>> Also, what do you mean with "We can use db's default values but they are
>> evaluated during migrations"?
>> On Oct 17, 2012, at 8:28 PM, Alexander Kurakin wrote:
>>
>> ROR doesn't realize functionality of setting default values for models.
>> We can use db's default values but they are evaluated during migrations. We
>> can't set default value i.e. Time.now. But there are completed gems that
>> realize this. I.e. default_value_for (https://github.com/**
>> FooBarWidget/default_value_for
>> **). Why not to merge it in rails? Thanks.
>>
>> --
>> 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/-/**u1PNgYmkABUJ
>> .
>> To post to this group, send email to rubyonra...@googlegroups.**com.
>> To unsubscribe from this group, send email to rubyonrails-co...@**
>> googlegroups.com.
>>
>> For more options, visit this group at http://groups.google.com/**
>> group/rubyonrails-core?hl=en
>> .
>>
>>
>>  Cumprimentos,
>> Luís Ferreira
>>
>>
>>
>>  --
> 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/-/Q5Pjbb3Oow0J.
>
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>

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

Re: [Rails-core] Suggestion: default values for models

[G. Sobrinho]

Using a after initialize does not respect if you set the attribute to
nil, like this:

Payment.new(:due_date => nil)


Also, it will mutate the already persisted objects if they are
persisted using a nil due date for example.


Another problem happens when you select specific attributes like:

Payment.select(:id, :person_id).first

It raises an exception on after initialize hook because there is no
due date attribute :(

On Thu, Oct 18, 2012 at 12:00 PM, Allen Madsen  wrote:
> This is relevant:
> http://stackoverflow.com/questions/328525/what-is-the-best-way-to-set-default-values-in-activerecord
>
> They mention using after_initialize.
>
> Allen Madsen
> http://www.allenmadsen.com
>
>
>
> On Thu, Oct 18, 2012 at 8:50 AM, Gabriel Sobrinho
>  wrote:
>>
>> That is a problem for me either.
>>
>> I can't use before_save callback because I need to show the default value
>> on forms.
>>
>> So, I have a date field and the default value is today, but when user open
>> the form, today must be on that field.
>>
>>
>> I'm setting this kind of default value on controller like that:
>>
>> def new
>>   @payment = Payment.new
>>   @payment.date = Date.current
>> end
>>
>> But this become a mess since I have "dynamic" default values in almost
>> every model of my application.
>>
>>
>> On Wednesday, October 17, 2012 4:41:55 PM UTC-3, Zamith wrote:
>>>
>>> Isn't this just the same as having a before_save callback where you
>>> define these default values?
>>>
>>> Also, what do you mean with "We can use db's default values but they are
>>> evaluated during migrations"?
>>> On Oct 17, 2012, at 8:28 PM, Alexander Kurakin wrote:
>>>
>>> ROR doesn't realize functionality of setting default values for models.
>>> We can use db's default values but they are evaluated during migrations. We
>>> can't set default value i.e. Time.now. But there are completed gems that
>>> realize this. I.e. default_value_for
>>> (https://github.com/FooBarWidget/default_value_for). Why not to merge it in
>>> rails? Thanks.
>>>
>>> --
>>> 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/-/u1PNgYmkABUJ.
>>> To post to this group, send email to rubyonra...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> rubyonrails-co...@googlegroups.com.
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/group/rubyonrails-core?hl=en.
>>>
>>>
>>> Cumprimentos,
>>> Luís Ferreira
>>>
>>>
>>>
>> --
>> 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/-/Q5Pjbb3Oow0J.
>>
>> 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.



-- 
Cheers,

Gabriel Sobrinho

-- 
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] Suggestion: default values for models

[Matt Jones]

On Oct 18, 2012, at 8:50 AM, Gabriel Sobrinho wrote:

> That is a problem for me either.
> 
> I can't use before_save callback because I need to show the default value on 
> forms.
> 
> So, I have a date field and the default value is today, but when user open 
> the form, today must be on that field.
> 
> 
> I'm setting this kind of default value on controller like that:
> 
> def new
>   @payment = Payment.new
>   @payment.date = Date.current
> end

One method I was surprised to not see on Stack Overflow - overriding the 
accessor:

class Payment < AR::Base

  def date
super || write_attribute(:date, Date.current)
  end

end

This still has the issue identified by G. Sobrinho, however, where explicitly 
setting an attribute to nil doesn't work quite right.

--Matt Jones

-- 
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] Re: Option for inserts/updates/deletes on the Postgres adapter to return all columns, not just the id

[Robert]

I like the idea of specifying it at the model level.  this way you can pick 
and choose.

On Monday, October 8, 2012 2:52:59 PM UTC-4, Abdelkader Boudih wrote:
>
>
>
> On Sunday, 7 October 2012 01:16:17 UTC+1, Robert wrote:
>>
>> By default with Rails, Postgres will return the id of a newly inserted 
>> record using returning "id". Sometimes when working with Postgres, 
>> tables will have triggers on them that modify the row's data while being 
>> saved. As such, it would be great to also provide an option for Postgres to 
>> also let insert/updates and deletes to use returning * (which will 
>> return the row as it looks after Postgres modified it).
>>
>> What are everyone's thoughts on this?
>>
>
> This will generate extra traffic. i think it  must be an option in the 
> model for example. 
> *
> *
> *self.returning = "*"*
> **
> *
> *
>

-- 
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/-/t5Xtn1dbTwYJ.
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] Disable Time Zone Conversion for Specified Column

[Karl Smith]

Pretty simple, I need to disable time zone conversion for specific columns. 
I will handle any TZ conversion manually, but I need Rails 3 to forego 
conversion in both writing and reading, and any AREL functions. But, I 
don't want to disable the conversion for non-specified attributes.

I know how to disable it for reading:

self.skip_time_zone_conversion_for_attributes = [:test_timestamp]


But this only works for reading. When writing the attribute, it still 
converts to UTC (yes, I tested this in 3.2.8).

How?

-- 
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/-/9JjYyc88WlsJ.
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] #asset_url helper method

[Scott Carleton]

Just putting this out there before I make a pull request.

Is there any interest in an asset_url method as a view helper?

It would work by using the config.action_controller.asset_host if it exists 
and prepending this to the results of asset_path.

I have found this necessary when writing html emails and needing a full url 
path for assets.  Since my CDN in the asset_host mirrors my assets in my 
app it makes perfect sense.  Might not be a common enough use case to put 
into core though.

-- 
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/-/itwdyjwfSJIJ.
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] Suggestion: default values for models

[Alexander Kurakin]

You can read here: 
https://github.com/FooBarWidget/default_value_for#when-not-to-use-default_value_for

среда, 17 октября 2012 г., 23:41:55 UTC+4 пользователь Zamith написал:
>
> Isn't this just the same as having a before_save callback where you define 
> these default values?
>
> Also, what do you mean with "We can use db's default values but they are 
> evaluated during migrations"?
> On Oct 17, 2012, at 8:28 PM, Alexander Kurakin wrote:
>
> ROR doesn't realize functionality of setting default values for models. We 
> can use db's default values but they are evaluated during migrations. We 
> can't set default value i.e. Time.now. But there are completed gems that 
> realize this. I.e. default_value_for (
> https://github.com/FooBarWidget/default_value_for). Why not to merge it 
> in rails? Thanks.
>
> -- 
> 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/-/u1PNgYmkABUJ.
> To post to this group, send email to rubyonra...@googlegroups.com
> .
> To unsubscribe from this group, send email to 
> rubyonrails-co...@googlegroups.com .
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
> Cumprimentos,
> Luís Ferreira
>
>
>  
>

-- 
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/-/jzPxLjH_J-YJ.
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] Disable Time Zone Conversion for Specified Column

[Godfrey Chan]

Is it possible to offset the "damage" from rails by writing your own attr 
reader/writer?

Sent from my phone

On 2012-10-18, at 4:39 PM, Karl Smith  wrote:

> Pretty simple, I need to disable time zone conversion for specific columns. I 
> will handle any TZ conversion manually, but I need Rails 3 to forego 
> conversion in both writing and reading, and any AREL functions. But, I don't 
> want to disable the conversion for non-specified attributes.
> 
> I know how to disable it for reading:
> 
>> self.skip_time_zone_conversion_for_attributes = [:test_timestamp]
> 
> But this only works for reading. When writing the attribute, it still 
> converts to UTC (yes, I tested this in 3.2.8).
> 
> How?
> -- 
> 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/-/9JjYyc88WlsJ.
> 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.