On Wed, Sep 9, 2009 at 4:02 PM, Rick DeNatale wrote:
> My normal practice when writing migrations which depend on model code
> is to put a migration specific model clase in the migration file
> itself, scoped inside the migration. The model mimics a subset of the
> one in app/models including on
Has anyone tried installing the mysql gem from Rubyforge on 1.9? It's stuff
like that that makes people hesitant to switch to 1.9. Projects on Rubyforge
who's owners have long abandoned it. There needs to be a way for other
people to patch gems and submit them and have a team of dedicated people to
> Come on guys, these are all open source projects. If something isn't
> working on a newer version, how much work would it be to get it to
> work?
I'm not sure if you're being sarcastic here, but I'll bite. It's very
often quite a bit of work. It's even more work to then maintain 1.8.6
and
On Wed, Sep 9, 2009 at 6:31 PM, Michael Koziarski wrote:
>
>> Doesn't this same problem exist always - whether you are going down or
>> up, or store your migrations in files or the database? Some would
>> consider it an antipattern to put any models or app classes in your
>> migrations.
>
> Some
> Doesn't this same problem exist always - whether you are going down or
> up, or store your migrations in files or the database? Some would
> consider it an antipattern to put any models or app classes in your
> migrations.
Some would be wrong if they considered that an anti pattern ;). The
va
On Wed, Sep 9, 2009 at 5:54 PM, Jeremy Evans wrote:
>
> On Wed, Sep 9, 2009 at 2:32 PM, Joris Verschoor wrote:
>>
>> I think if we don't go to ruby 1.9, ruby and rails will get stuck in a
>> similar thing that happened with java 1.2 1.4 and 1.5.
>
> Certainly, supporting the latest version of rub
On Sep 9, 2009, at 2:54 PM, Jeremy Evans wrote:
> On Wed, Sep 9, 2009 at 2:32 PM, Joris Verschoor
> wrote:
>>
>> I think if we don't go to ruby 1.9, ruby and rails will get stuck
>> in a
>> similar thing that happened with java 1.2 1.4 and 1.5.
>
> Certainly, supporting the latest version of
On Wed, Sep 9, 2009 at 2:32 PM, Joris Verschoor wrote:
>
> I think if we don't go to ruby 1.9, ruby and rails will get stuck in a
> similar thing that happened with java 1.2 1.4 and 1.5.
Certainly, supporting the latest version of ruby is a good thing.
However, forcing people to upgrade their ru
I think if we don't go to ruby 1.9, ruby and rails will get stuck in a
similar thing that happened with java 1.2 1.4 and 1.5.
Come on guys, these are all open source projects. If something isn't
working on a newer version, how much work would it be to get it to
work?
just my 2cents
On Wed, Sep
Hey Josh,
I think this patch by José Valim, which is in my queue to work on this
week, will solve this problem for you:
https://rails.lighthouseapp.com/projects/8994/tickets/2904-avoid-copying-errors-from-child-to-parent-on-autosave
Cheers,
Eloy
On 9 sep 2009, at 19:36, Josh wrote:
>
> This
On Wed, Sep 9, 2009 at 1:33 PM, Jeremy Evans wrote:
>
> On Wed, Sep 9, 2009 at 12:17 AM, Yehuda Katz wrote:
>> Hey Jeremy,
>> I apologize for the delay.
>> The basic idea is that there are a number of issues in Ruby 1.8.6 that are
>> simply not going to be fixed
> First, thank you very much for
This line o' code in autosave_association.rb is a little bit weird
imo.
attribute = "#{reflection.name}_#{attribute}"
Line 252 on master at the moment.
It's used in at least two places I can tell (I haven't looked very
hard), accepts_nested_attributes and validates_associated. The string
that
On Wed, Sep 9, 2009 at 12:17 AM, Yehuda Katz wrote:
> Hey Jeremy,
> I apologize for the delay.
> The basic idea is that there are a number of issues in Ruby 1.8.6 that are
> simply not going to be fixed
> (see http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7/ChangeLog for a
> complete list), and t
Since database.yml gets ERB'd, I've seen a trick where the database name is
lazy evaluated w/ the output from a git branch command. This way each
branch has a seperate DB. There is a bit of manual work involved to make
sure you create the database each time you create a new branch, but that's
sol
On Wed, Sep 9, 2009 at 5:03 AM, Chris wrote:
>
> I see sublime elegance in having the DB store the DDL to revert
> migrations. I haven't worked with large teams in years, but I see the
> dilemma Steven is addressing:
>
> The common DB is at Rev N
> User (or branch) A migrates common DB up to Rev
On Wed, Sep 9, 2009 at 3:36 PM, Luca Guidi wrote:
> You can safely use Passenger with Ruby 1.9.1, avoiding REE.
I wasn't asking whether you can use Passenger with 1.9.1. I'm talking
the about these REE announcements on the passenger (sorry, 'Phusion')
website:
http://blog.phusion.nl/2009/05/27/r
You can safely use Passenger with Ruby 1.9.1, avoiding REE.
- Luca
--
lucaguidi.com
twitter.com/jodosha
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email
On Wed, Sep 9, 2009 at 2:48 PM, Chad Pytel wrote:
>> The present (not the future) of Ruby it's 1.9.1, honestly don't know
>> why the majority (myself included) is still on the old-and-beloved
>> 1.8.6.
>
> Our primary reason is because none of the main hosting services
> support 1.9. EngineYard,
> The present (not the future) of Ruby it's 1.9.1, honestly don't know
> why the majority (myself included) is still on the old-and-beloved
> 1.8.6.
Our primary reason is because none of the main hosting services
support 1.9. EngineYard, Rails Machine, etc. all are still on 1.8.6.
We ar
I see sublime elegance in having the DB store the DDL to revert
migrations. I haven't worked with large teams in years, but I see the
dilemma Steven is addressing:
The common DB is at Rev N
User (or branch) A migrates common DB up to Rev N + 1
User (or branch) B is "checked out" and expects comm
The EY team will maintain 1.8.x branch only for security issues, I don't
think they will backport all the 1.9.x features. Because it's a non-sense.
The present (not the future) of Ruby it's 1.9.1, honestly don't know why the
majority (myself included) is still on the old-and-beloved 1.8.6.
The "Bi
On Tue, Sep 8, 2009 at 2:01 PM, Michael Koziarski wrote:
> That'd work only for cases where your down migrations *only* change
> the schema, they don't touch models or any other ruby code. Otherwise
> there's no guarantee that those models are available when the system
> tries to downgrade.
Doe
Hey Jeremy,
I apologize for the delay.
The basic idea is that there are a number of issues in Ruby 1.8.6 that are
simply not going to be fixed (see
http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7/ChangeLog for a complete
list), and targeting 1.8.6 means always having to make sure that new
features
23 matches
Mail list logo
