Rails core - Aug 2008 - Active record association not working with string id

Hello,
I''m stuck with an issue where the active record associations are not
working.
I have created the required migrations.In my migrations I need the id
to be a string and not an integer as the usual rails id.I have
declared the associations in the models.
But for some reason I''m not able to access the data using the regular
relationships .
I get the error as below:
NoMethodError: undefined method `product_skus'' for #<Product:
0xb6fe5630>
        from /root/Desktop/trunk/vendor/rails/activerecord/lib/
active_record/attribute_methods.rb:205:in `method_missing''
        from (irb):25
I''m working on rails 2.1.0

Please let me know if there is any creep we can do to this.
Any help appreciated.
kranthi

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

Developers are rarely using primary keys which are not auto-generated,
incremental integers. There might be a bug with associations in that case,
but you must take proper steps to report it. Open up a ticket in Rails''
bug
tracker and provide ActiveRecord code that creates the association,
structure of your tables and generated SQL on association lookups that fail
for you.
Still, judging by your error message, I think that your problem may be in
user code, not in the framework.

# Mislav


On Tue, Aug 12, 2008 at 11:46, kranthi <kranthicu@gmail.com> wrote:
>
> Hello,
> I''m stuck with an issue where the active record associations are
not
> working.
> I have created the required migrations.In my migrations I need the id
> to be a string and not an integer as the usual rails id.I have
> declared the associations in the models.
> But for some reason I''m not able to access the data using the
regular
> relationships .
> I get the error as below:
> NoMethodError: undefined method `product_skus'' for #<Product:
> 0xb6fe5630>
>        from /root/Desktop/trunk/vendor/rails/activerecord/lib/
> active_record/attribute_methods.rb:205:in `method_missing''
>        from (irb):25
> I''m working on rails 2.1.0
>
> Please let me know if there is any creep we can do to this.
> Any help appreciated.
> kranthi
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Hey,
Thanks for the reply.Below I'm writing the code which is responsible for the
action I have posted.

class Post < ActiveRecord::Base
  has_many :comments
end

class Comment < ActiveRecord::Base
  belongs_to :posts
end

class CreatePosts < ActiveRecord::Migration
  def self.up
    create_table :posts |, :id=>false  do |t|
      t.string :id , :null =>  false
      t.string "title"
    end
execute("ALTER TABLE posts ADD PRIMARY KEY (id)")
  end

  def self.down
    drop_table :posts
  end
end

Is the procedure wrong or something?The same way worked when the primary key
id is a string.
Thank you.
kranthi


On Tue, Aug 12, 2008 at 4:14 PM, Mislav Marohnić
<mislav.marohnic@gmail.com>wrote:
> Developers are rarely using primary keys which are not auto-generated,
> incremental integers. There might be a bug with associations in that case,
> but you must take proper steps to report it. Open up a ticket in Rails'
bug
> tracker and provide ActiveRecord code that creates the association,
> structure of your tables and generated SQL on association lookups that fail
> for you.
> Still, judging by your error message, I think that your problem may be in
> user code, not in the framework.
>
> # Mislav
>
>
> On Tue, Aug 12, 2008 at 11:46, kranthi <kranthicu@gmail.com> wrote:
>
>>
>> Hello,
>> I'm stuck with an issue where the active record associations are
not
>> working.
>> I have created the required migrations.In my migrations I need the id
>> to be a string and not an integer as the usual rails id.I have
>> declared the associations in the models.
>> But for some reason I'm not able to access the data using the
regular
>> relationships .
>> I get the error as below:
>> NoMethodError: undefined method `product_skus' for #<Product:
>> 0xb6fe5630>
>>        from /root/Desktop/trunk/vendor/rails/activerecord/lib/
>> active_record/attribute_methods.rb:205:in `method_missing'
>>        from (irb):25
>> I'm working on rails 2.1.0
>>
>> Please let me know if there is any creep we can do to this.
>> Any help appreciated.
>> kranthi
>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12 Aug 2008, at 11:44, Mislav Marohnić wrote:
> Developers are rarely using primary keys which are not auto- 
> generated, incremental integers. There might be a bug with  
> associations in that case, but you must take proper steps to report  
> it. Open up a ticket in Rails'' bug tracker and provide
ActiveRecord
> code that creates the association, structure of your tables and  
> generated SQL on association lookups that fail for you.
>
There are at least some tests that cover associations with string keys  
(which I wrote after haven broken stuff in that case :oops).
Hard to say without seeing any of the actual code though (and errors  
in that area tend to result on borked queries rather than errors like  
the one below)

Fred
> Still, judging by your error message, I think that your problem may  
> be in user code, not in the framework.
>
> # Mislav
>
>
> On Tue, Aug 12, 2008 at 11:46, kranthi <kranthicu@gmail.com> wrote:
>
> Hello,
> I''m stuck with an issue where the active record associations are
not
> working.
> I have created the required migrations.In my migrations I need the id
> to be a string and not an integer as the usual rails id.I have
> declared the associations in the models.
> But for some reason I''m not able to access the data using the
regular
> relationships .
> I get the error as below:
> NoMethodError: undefined method `product_skus'' for #<Product:
> 0xb6fe5630>
>        from /root/Desktop/trunk/vendor/rails/activerecord/lib/
> active_record/attribute_methods.rb:205:in `method_missing''
>        from (irb):25
> I''m working on rails 2.1.0
>
> Please let me know if there is any creep we can do to this.
> Any help appreciated.
> kranthi
>
>
>
>
> >

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

Just curious, is it actually a bug when a user decides not to use
Rails' convention of auto-incrementing integer as id and something
breaks as a result?

RSL

On Tue, Aug 12, 2008 at 6:44 AM, Mislav Marohnić
<mislav.marohnic@gmail.com> wrote:
> Developers are rarely using primary keys which are not auto-generated,
> incremental integers. There might be a bug with associations in that case,
> but you must take proper steps to report it. Open up a ticket in Rails'
bug
> tracker and provide ActiveRecord code that creates the association,
> structure of your tables and generated SQL on association lookups that fail
> for you.
> Still, judging by your error message, I think that your problem may be in
> user code, not in the framework.
> # Mislav
>
> On Tue, Aug 12, 2008 at 11:46, kranthi <kranthicu@gmail.com> wrote:
>>
>> Hello,
>> I'm stuck with an issue where the active record associations are
not
>> working.
>> I have created the required migrations.In my migrations I need the id
>> to be a string and not an integer as the usual rails id.I have
>> declared the associations in the models.
>> But for some reason I'm not able to access the data using the
regular
>> relationships .
>> I get the error as below:
>> NoMethodError: undefined method `product_skus' for #<Product:
>> 0xb6fe5630>
>>        from /root/Desktop/trunk/vendor/rails/activerecord/lib/
>> active_record/attribute_methods.rb:205:in `method_missing'
>>        from (irb):25
>> I'm working on rails 2.1.0
>>
>> Please let me know if there is any creep we can do to this.
>> Any help appreciated.
>> kranthi
>>
>>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Aug 12, 7:21 pm, RSL <sco...@gmail.com> wrote:
> Just curious, is it actually a bug when a user decides not to use
> Rails'' convention of auto-incrementing integer as id and something
> breaks as a result?
Yeah. Are non-integer primary keys actually supported?
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Tue, Aug 12, 2008 at 9:41 PM, Hongli Lai <honglilai@gmail.com>
wrote:
>
> On Aug 12, 7:21 pm, RSL <sco...@gmail.com> wrote:
>> Just curious, is it actually a bug when a user decides not to use
>> Rails'' convention of auto-incrementing integer as id and
something
>> breaks as a result?
>
> Yeah. Are non-integer primary keys actually supported?
They''re *meant* to be, but given how much more common it is to use
integer keys, it wouldn''t be surprising if a bug had crept in.

-- 
Cheers

Koz

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

Non-integer keys have been very well supported, up to at least 2.0.2.
I wrote a plugin that uses UUID primary keys and have only had one
problem in the past two years (and Frederick fixed it quickly).  And
most plugin providers also support non-integer primary keys (two years
ago, for example the developer of acts_as_ferret retrofitted string
keys in short order).

And the support is not just a situation where you can hack Rails code
to do it.  It''s actually pretty easy... Rails provides methods to
define the primary key name and in the remainder of the code no
assumptions are made as to the type value used for the PK.  My plugin
is less than 60 lines of code but the reality is that you could write
your own in ten lines of code.

There are two caveats that I don''t expect will be addressed by Rails:
migrations with deviant primary keys and Foxy Fixtures with deviant
primary keys.  Although in both cases my plugin addresses the problems
nicely -but with monkey patches.  In fact, in the case of Foxy
Fixtures, I''ve restored about 90% of the Foxy Functionality when using
UUID primary keys.

Given the very high level of support for string keys already in place,
it would be a shame to break it now.

I won''t get into the religion of meaningful keys, but know that many
programmers prefer to have their PKs correlate to "real world"
attributes that are not integers.  This is particularly true in legacy
applications.

My plugin is available here for checkout:

   svn://cho.hapgoods.com/groupsmarts/uuid_primary_ke

and here for browsing so you can see just how simple it is:

   http://cho.hapgoods.com/projects/groupsmarts/browser/uuid_primary_key

-Chris

PS - I will go so far as to say that in an ideal world, Rails would
offer support for UUID primary keys out of the box.  It is dead simple
and provides many advantages in distributed applications -Adobe Air
and other apps with standalone clients come are good examples.  And
UUID are very analagous to the auto-incrementing integers Rails
already uses: they can be generated at the database and they are
guaranteed to be unique.

On Aug 12, 3:45 pm, "Michael Koziarski" <mich...@koziarski.com>
wrote:
> On Tue, Aug 12, 2008 at 9:41 PM, Hongli Lai <hongli...@gmail.com>
wrote:
>
> > On Aug 12, 7:21 pm, RSL <sco...@gmail.com> wrote:
> >> Just curious, is it actually a bug when a user decides not to use
> >> Rails'' convention of auto-incrementing integer as id and
something
> >> breaks as a result?
>
> > Yeah. Are non-integer primary keys actually supported?
>
> They''re *meant* to be, but given how much more common it is to use
> integer keys, it wouldn''t be surprising if a bug had crept in.
>
> --
> Cheers
>
> Koz
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

> Non-integer keys have been very well supported, up to at least 2.0.2.
> I wrote a plugin that uses UUID primary keys and have only had one
> problem in the past two years (and Frederick fixed it quickly).  And
> most plugin providers also support non-integer primary keys (two years
> ago, for example the developer of acts_as_ferret retrofitted string
> keys in short order).
As I mentioned earlier, these are meant to work, and any bugs
resulting from non-integer keys are just that.  Bugs :)  There''s no
reason to remove them.
> I won''t get into the religion of meaningful keys, but know that
many
> programmers prefer to have their PKs correlate to "real world"
> attributes that are not integers.  This is particularly true in legacy
> applications.
Natural keys aren''t something that we want to encourage.  Anyone
who''s
been told "sorry, you can''t change your email address as
it''s the pk
of the user table" will understand.  But UUIDs and other opaque
strings can and should be supported :)

> PS - I will go so far as to say that in an ideal world, Rails would
> offer support for UUID primary keys out of the box.  It is dead simple
> and provides many advantages in distributed applications -Adobe Air
> and other apps with standalone clients come are good examples.  And
> UUID are very analagous to the auto-incrementing integers Rails
> already uses: they can be generated at the database and they are
> guaranteed to be unique.
If you''d like to prepare a patch for this, we can take a look at it
for inclusion.  If it''s non-intrusive and simple enough, perhaps we
can include it.  Though your urls must be HUGE ;)
> On Aug 12, 3:45 pm, "Michael Koziarski"
<mich...@koziarski.com> wrote:
>> On Tue, Aug 12, 2008 at 9:41 PM, Hongli Lai <hongli...@gmail.com>
wrote:
>>
>> > On Aug 12, 7:21 pm, RSL <sco...@gmail.com> wrote:
>> >> Just curious, is it actually a bug when a user decides not to
use
>> >> Rails'' convention of auto-incrementing integer as id
and something
>> >> breaks as a result?
>>
>> > Yeah. Are non-integer primary keys actually supported?
>>
>> They''re *meant* to be, but given how much more common it is to
use
>> integer keys, it wouldn''t be surprising if a bug had crept in.
>>
>> --
>> Cheers
>>
>> Koz
> >
>


-- 
Cheers

Koz

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

"Though your urls must be HUGE"

True dat.  But I''ve been dreaming of a git-like approach that
(optionally) takes just the first six or seven characters -enough to
practically ensure uniqueness.  That way smart clients could send big
nasty request URLs but a browser-driven app could generate "less ugly"
URLs.  As always with string keys, performance of big random keys and
a LIKE construct could be an issue...

Anyway about my plugin-that-dreams-of-being-in-core... I''ve got some
questions about how to go about INCREMENTALLY bringing in the
functionality.  Right now I see the task broken into three
components.  And some of them aren''t really baked yet and I''m
not the
right one to finish the job:

 **1. Core support in ActiveRecord::Base for generating a UUID string
(currently 36 characters) on create and using that for the primary
key: DONE (requires the uuidtools gem).  This gets you 95% of the
value and is, frankly, a trivial implementation.  But without #2 and
#3 below, it probably is going to seem broken to many.

 **2. Support for Foxy Fixtures: STARTED.  I allow the generation of a
stable UUID from the fixture label (tricky and cool!) but I have not
added support for an automatic application of these UUIDs to keys in
the fixture files themselves.  And there is a fundamental problem
here...

 **3. Support for Migrations: STARTED.  I provide new types that are
just syntactic sugar.  There are some (minor) long-term issues here as
well.

So, really only #1 is ready for prime time.  FF and Migrations still
need help.  If I go to the trouble of putting this up on GitHub,
anybody want to help take it over the finish line?

On Aug 14, 6:28 am, "Michael Koziarski" <mich...@koziarski.com>
wrote:
> > Non-integer keys have been very well supported, up to at least 2.0.2.
> > I wrote a plugin that uses UUID primary keys and have only had one
> > problem in the past two years (and Frederick fixed it quickly).  And
> > most plugin providers also support non-integer primary keys (two years
> > ago, for example the developer of acts_as_ferret retrofitted string
> > keys in short order).
>
> As I mentioned earlier, these are meant to work, and any bugs
> resulting from non-integer keys are just that.  Bugs :)  There''s
no
> reason to remove them.
>
> > I won''t get into the religion of meaningful keys, but know
that many
> > programmers prefer to have their PKs correlate to "real
world"
> > attributes that are not integers.  This is particularly true in legacy
> > applications.
>
> Natural keys aren''t something that we want to encourage.  Anyone
who''s
> been told "sorry, you can''t change your email address as
it''s the pk
> of the user table" will understand.  But UUIDs and other opaque
> strings can and should be supported :)
>
> > PS - I will go so far as to say that in an ideal world, Rails would
> > offer support for UUID primary keys out of the box.  It is dead simple
> > and provides many advantages in distributed applications -Adobe Air
> > and other apps with standalone clients come are good examples.  And
> > UUID are very analagous to the auto-incrementing integers Rails
> > already uses: they can be generated at the database and they are
> > guaranteed to be unique.
>
> If you''d like to prepare a patch for this, we can take a look at
it
> for inclusion.  If it''s non-intrusive and simple enough, perhaps
we
> can include it.  Though your urls must be HUGE ;)
>
>
>
> > On Aug 12, 3:45 pm, "Michael Koziarski"
<mich...@koziarski.com> wrote:
> >> On Tue, Aug 12, 2008 at 9:41 PM, Hongli Lai
<hongli...@gmail.com> wrote:
>
> >> > On Aug 12, 7:21 pm, RSL <sco...@gmail.com> wrote:
> >> >> Just curious, is it actually a bug when a user decides
not to use
> >> >> Rails'' convention of auto-incrementing integer
as id and something
> >> >> breaks as a result?
>
> >> > Yeah. Are non-integer primary keys actually supported?
>
> >> They''re *meant* to be, but given how much more common it
is to use
> >> integer keys, it wouldn''t be surprising if a bug had
crept in.
>
> >> --
> >> Cheers
>
> >> Koz
>
> --
> Cheers
>
> Koz
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Yeah It would be my pleasure to help you in any such issues....
kranthi.

On Thu, Aug 14, 2008 at 5:55 PM, Chris Cruft <cch1@hapgoods.com> wrote:
>
> "Though your urls must be HUGE"
>
> True dat.  But I''ve been dreaming of a git-like approach that
> (optionally) takes just the first six or seven characters -enough to
> practically ensure uniqueness.  That way smart clients could send big
> nasty request URLs but a browser-driven app could generate "less
ugly"
> URLs.  As always with string keys, performance of big random keys and
> a LIKE construct could be an issue...
>
> Anyway about my plugin-that-dreams-of-being-in-core... I''ve got
some
> questions about how to go about INCREMENTALLY bringing in the
> functionality.  Right now I see the task broken into three
> components.  And some of them aren''t really baked yet and
I''m not the
> right one to finish the job:
>
>  **1. Core support in ActiveRecord::Base for generating a UUID string
> (currently 36 characters) on create and using that for the primary
> key: DONE (requires the uuidtools gem).  This gets you 95% of the
> value and is, frankly, a trivial implementation.  But without #2 and
> #3 below, it probably is going to seem broken to many.
>
>  **2. Support for Foxy Fixtures: STARTED.  I allow the generation of a
> stable UUID from the fixture label (tricky and cool!) but I have not
> added support for an automatic application of these UUIDs to keys in
> the fixture files themselves.  And there is a fundamental problem
> here...
>
>  **3. Support for Migrations: STARTED.  I provide new types that are
> just syntactic sugar.  There are some (minor) long-term issues here as
> well.
>
> So, really only #1 is ready for prime time.  FF and Migrations still
> need help.  If I go to the trouble of putting this up on GitHub,
> anybody want to help take it over the finish line?
>
> On Aug 14, 6:28 am, "Michael Koziarski"
<mich...@koziarski.com> wrote:
> > > Non-integer keys have been very well supported, up to at least
2.0.2.
> > > I wrote a plugin that uses UUID primary keys and have only had
one
> > > problem in the past two years (and Frederick fixed it quickly). 
And
> > > most plugin providers also support non-integer primary keys (two
years
> > > ago, for example the developer of acts_as_ferret retrofitted
string
> > > keys in short order).
> >
> > As I mentioned earlier, these are meant to work, and any bugs
> > resulting from non-integer keys are just that.  Bugs :) 
There''s no
> > reason to remove them.
> >
> > > I won''t get into the religion of meaningful keys, but
know that many
> > > programmers prefer to have their PKs correlate to "real
world"
> > > attributes that are not integers.  This is particularly true in
legacy
> > > applications.
> >
> > Natural keys aren''t something that we want to encourage. 
Anyone who''s
> > been told "sorry, you can''t change your email address as
it''s the pk
> > of the user table" will understand.  But UUIDs and other opaque
> > strings can and should be supported :)
> >
> > > PS - I will go so far as to say that in an ideal world, Rails
would
> > > offer support for UUID primary keys out of the box.  It is dead
simple
> > > and provides many advantages in distributed applications -Adobe
Air
> > > and other apps with standalone clients come are good examples. 
And
> > > UUID are very analagous to the auto-incrementing integers Rails
> > > already uses: they can be generated at the database and they are
> > > guaranteed to be unique.
> >
> > If you''d like to prepare a patch for this, we can take a look
at it
> > for inclusion.  If it''s non-intrusive and simple enough,
perhaps we
> > can include it.  Though your urls must be HUGE ;)
> >
> >
> >
> > > On Aug 12, 3:45 pm, "Michael Koziarski"
<mich...@koziarski.com> wrote:
> > >> On Tue, Aug 12, 2008 at 9:41 PM, Hongli Lai
<hongli...@gmail.com>
> wrote:
> >
> > >> > On Aug 12, 7:21 pm, RSL <sco...@gmail.com> wrote:
> > >> >> Just curious, is it actually a bug when a user
decides not to use
> > >> >> Rails'' convention of auto-incrementing
integer as id and something
> > >> >> breaks as a result?
> >
> > >> > Yeah. Are non-integer primary keys actually supported?
> >
> > >> They''re *meant* to be, but given how much more
common it is to use
> > >> integer keys, it wouldn''t be surprising if a bug had
crept in.
> >
> > >> --
> > >> Cheers
> >
> > >> Koz
> >
> > --
> > Cheers
> >
> > Koz
> >
>
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---