Rails - Jul 2005 - Table called 'lens', won't work....

First off, I name my database tables for the type of object that they 
contains, which implies no pluralization.  I have a database table 
called ''Lens'', for camera lenses.  When I execute this
command:

    script/generate scaffold Lens

followed by a fetch to:

    http://localhost:2000/lens

I get this error:

    uninitialized constant Len

with this stack trace:

|/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/dependencies.rb:186:in
`const_missing''
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/core_ext/string/../../inflector.rb:59:in
`const_get''
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/core_ext/string/../../inflector.rb:59:in
`constantize''
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/core_ext/string/../../inflector.rb:58:in
`inject''
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/core_ext/string/../../inflector.rb:58:in
`each''
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/core_ext/string/../../inflector.rb:58:in
`inject''
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/core_ext/string/../../inflector.rb:58:in
`constantize''
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/core_ext/string/inflections.rb:44:in
`constantize''
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/pagination.rb:169:in
`paginator_and_collection_for''
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/pagination.rb:111:in
`paginate''
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/base.rb:748:in
`send''
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/base.rb:748:in
`perform_action_without_filters''
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/filters.rb:295:in
`perform_action_without_benchmark''
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/benchmarking.rb:41:in
`perform_action_without_rescue''
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/benchmarking.rb:41:in
`measure''
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/benchmarking.rb:41:in
`perform_action_without_rescue''
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/rescue.rb:80:in
`perform_action''
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/base.rb:348:in
`send''
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/base.rb:348:in
`process''
/usr/local/lib/ruby/gems/1.8/gems/rails-0.13.0/lib/dispatcher.rb:32:in
`dispatch''
/usr/local/lib/ruby/gems/1.8/gems/rails-0.13.0/lib/webrick_server.rb:103:in
`handle_dispatch''
/usr/local/lib/ruby/gems/1.8/gems/rails-0.13.0/lib/webrick_server.rb:69:in
`service''
/usr/local/lib/ruby/1.8/webrick/httpserver.rb:104:in `service''
/usr/local/lib/ruby/1.8/webrick/httpserver.rb:65:in `run''
/usr/local/lib/ruby/1.8/webrick/server.rb:155:in `start_thread''
/usr/local/lib/ruby/1.8/webrick/server.rb:144:in `start''
/usr/local/lib/ruby/1.8/webrick/server.rb:144:in `start_thread''
/usr/local/lib/ruby/1.8/webrick/server.rb:94:in `start''
/usr/local/lib/ruby/1.8/webrick/server.rb:89:in `each''
/usr/local/lib/ruby/1.8/webrick/server.rb:89:in `start''
/usr/local/lib/ruby/1.8/webrick/server.rb:79:in `start''
/usr/local/lib/ruby/1.8/webrick/server.rb:79:in `start''
/usr/local/lib/ruby/gems/1.8/gems/rails-0.13.0/lib/webrick_server.rb:55:in
`dispatch''|

|This error occured while loading the following files:
   len.rb|

There is no ''len.rb'' file.  I also have this statement in my
environment.rb:

    ActiveRecord::Base.pluralize_table_names = false

But this doesn''t seem to have any effect on the generator.

I''m running rails 0.13, which was supposed to have fixed one or more 
pluralization errors, but it appears that this particular table name 
still causes the error.  So, two things:

1. How do I fix this, and
2. Is there any way that pluralization can be *completely* turned off?  
While I like Rails and all the work it does for you behind the scenes, 
pluralization drives me nuts. 

Thanks!

    -klm.

Ken Miller <klm-qD6opK7ZJR2ttCpgsWEBFlaTQe2KTcn/@public.gmane.org> writes:
> First off, I name my database tables for the type of object that they 
> contains, which implies no pluralization.  I have a database table 
> called ''Lens'', for camera lenses.  When I execute this
command:
Table names are supposed to be plural.  Name you table
''lenses''.
-- 
doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org

While I do agree with the idea of having pluralized table names, this
is a totally bogus response to Ken''s question...

On 7/10/05, Doug Alcorn <doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org>
wrote:
> Ken Miller <klm-qD6opK7ZJR2ttCpgsWEBFlaTQe2KTcn/@public.gmane.org>
writes:
> 
> > First off, I name my database tables for the type of object that they
> > contains, which implies no pluralization.  I have a database table
> > called ''Lens'', for camera lenses.  When I execute
this command:
> 
> Table names are supposed to be plural.  Name you table
''lenses''.
> --
> doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 7/9/05, Ken Miller
<klm-qD6opK7ZJR2ttCpgsWEBFlaTQe2KTcn/@public.gmane.org>
wrote:
> First off, I name my database tables for the type of object that they
> contains, which implies no pluralization.  I have a database table
> called ''Lens'', for camera lenses.  When I execute this
command:
> 
>     script/generate scaffold Lens
> 
> followed by a fetch to:
> 
>     http://localhost:2000/lens
> 
> I get this error:
> 
>     uninitialized constant Len
> 
> with this stack trace:
> 
>
|/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/dependencies.rb:186:in
`const_missing''
>
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/core_ext/string/../../inflector.rb:59:in
`const_get''
>
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/core_ext/string/../../inflector.rb:59:in
`constantize''
>
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/core_ext/string/../../inflector.rb:58:in
`inject''
>
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/core_ext/string/../../inflector.rb:58:in
`each''
>
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/core_ext/string/../../inflector.rb:58:in
`inject''
>
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/core_ext/string/../../inflector.rb:58:in
`constantize''
>
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.0/lib/active_support/core_ext/string/inflections.rb:44:in
`constantize''
>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/pagination.rb:169:in
`paginator_and_collection_for''
>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/pagination.rb:111:in
`paginate''
>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/base.rb:748:in
`send''
>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/base.rb:748:in
`perform_action_without_filters''
>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/filters.rb:295:in
`perform_action_without_benchmark''
>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/benchmarking.rb:41:in
`perform_action_without_rescue''
>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/benchmarking.rb:41:in
`measure''
>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/benchmarking.rb:41:in
`perform_action_without_rescue''
>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/rescue.rb:80:in
`perform_action''
>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/base.rb:348:in
`send''
>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.9.0/lib/action_controller/base.rb:348:in
`process''
> /usr/local/lib/ruby/gems/1.8/gems/rails-0.13.0/lib/dispatcher.rb:32:in
`dispatch''
> /usr/local/lib/ruby/gems/1.8/gems/rails-0.13.0/lib/webrick_server.rb:103:in
`handle_dispatch''
> /usr/local/lib/ruby/gems/1.8/gems/rails-0.13.0/lib/webrick_server.rb:69:in
`service''
> /usr/local/lib/ruby/1.8/webrick/httpserver.rb:104:in `service''
> /usr/local/lib/ruby/1.8/webrick/httpserver.rb:65:in `run''
> /usr/local/lib/ruby/1.8/webrick/server.rb:155:in `start_thread''
> /usr/local/lib/ruby/1.8/webrick/server.rb:144:in `start''
> /usr/local/lib/ruby/1.8/webrick/server.rb:144:in `start_thread''
> /usr/local/lib/ruby/1.8/webrick/server.rb:94:in `start''
> /usr/local/lib/ruby/1.8/webrick/server.rb:89:in `each''
> /usr/local/lib/ruby/1.8/webrick/server.rb:89:in `start''
> /usr/local/lib/ruby/1.8/webrick/server.rb:79:in `start''
> /usr/local/lib/ruby/1.8/webrick/server.rb:79:in `start''
> /usr/local/lib/ruby/gems/1.8/gems/rails-0.13.0/lib/webrick_server.rb:55:in
`dispatch''|
> 
> |This error occured while loading the following files:
>    len.rb|
> 
> There is no ''len.rb'' file.  I also have this statement in
my environment.rb:
> 
>     ActiveRecord::Base.pluralize_table_names = false
> 
> But this doesn''t seem to have any effect on the generator.
> 
> I''m running rails 0.13, which was supposed to have fixed one or
more
> pluralization errors, but it appears that this particular table name
> still causes the error.  So, two things:
> 
> 1. How do I fix this, and
> 2. Is there any way that pluralization can be *completely* turned off?
> While I like Rails and all the work it does for you behind the scenes,
> pluralization drives me nuts.
> 
> Thanks!
> 
>     -klm.
> 

Ken, 

The problem is because the paginate method is trying to singularize
the table name still.  What you need to do is tell paginate that your
model is called Lens, not Len.

I''ve followed your steps and you should see this on your error page:

app/controllers/lens_controller.rb:10:in `list''
app/controllers/lens_controller.rb:5:in `index''
script/server:48

Take a look at line 10 in the list method, and you see this:

    @lens_pages, @lens = paginate :lens, :per_page => 10

If you read the docs on the paginate method [1], you see that it can
accept a :class_name option.  So we change it to this:

    @lens_pages, @lens = paginate :lens, :per_page => 10, :class_name =>
''Lens''


Restart webrick and all seems to be well!

Hope this helps.

Jason


[1] 
http://ap.rubyonrails.com/classes/ActionController/Pagination.html#M000041
> 
> 
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Jason Foreman <threeve.org-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
writes:
> While I do agree with the idea of having pluralized table names,
> this is a totally bogus response to Ken''s question...
No, it''s not.  His problem was that AR (or specifically paginate)
improperly guessed the proper class name based -- as you pointed out
in his message.

Rails is "convention over configuration".  The idea is to learn the
convention and make your life simpler.  If he redid his implementation
with the proper class/table name his problem would have come out in
the wash.

Yes, he can override the defaults and make this particular problem go
away.  And the next one, he''ll have to another override, and another.
Or he can choose to follow the Rails convention and the rest will be
smoother.
>
> On 7/10/05, Doug Alcorn
<doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org> wrote:
>> Ken Miller
<klm-qD6opK7ZJR2ttCpgsWEBFlaTQe2KTcn/@public.gmane.org> writes:
>> 
>> > First off, I name my database tables for the type of object that
>> > they contains, which implies no pluralization.  I have a database
>> > table called ''Lens'', for camera lenses.  When I
execute this
>> > command:
>> 
>> Table names are supposed to be plural.  Name you table
''lenses''.
-- 
doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org

On 7/10/05, Doug Alcorn <doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org>
wrote:
> Rails is "convention over configuration".  The idea is to learn
the
> convention and make your life simpler.  If he redid his implementation
> with the proper class/table name his problem would have come out in
> the wash.
As someone new to rails, I''m going to have to disagree with this. Some
of us are glueing rails onto existing database schemas that have
"aged" over decades in some cases. We can not just "redo our
implementation".  One of the things that''s bit me, repeatedly,
with
Rails is that it makes dozens, if not hundreds of assumptions, about
how things should work.  This makes for an amazingly fast development
cycle when Rails is driving development, and when we can control
things that way.

When, instead, we are retrofiting the framework onto something already
in place, it blows up all over the place.  I''ve started documenting
some of those, but it would be nice if those "assumptions" (like
pluralizations) could simply be turned off when appropriate.  That
would make Rails substantially more usable for existing applications,
rather than having to fight against it constantly.

Having said that, it''s still an impressive framework, I just want it
to be better.

Chris
-- 
| Christopher Petrilli
| petrilli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

For me, I didn''t want to use plural tables, and setting this in
environment.rb fixed the majority of the drama:
ActiveRecord::Base.pluralize_table_names = false

It didn''t, however, make the test fixtures come out with the singular
names. This causes tests to fail as when the fixture is loaded it
looks for a table with the same name as the fixture. Renaming them
fixed this, but it would have been nice if it had have obeyed the
config too.

Hope that helps a little,
Dan

On 7/11/05, Christopher Petrilli
<petrilli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 7/10/05, Doug Alcorn
<doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org> wrote:
> > Rails is "convention over configuration".  The idea is to
learn the
> > convention and make your life simpler.  If he redid his implementation
> > with the proper class/table name his problem would have come out in
> > the wash.
> 
> As someone new to rails, I''m going to have to disagree with this.
Some
> of us are glueing rails onto existing database schemas that have
> "aged" over decades in some cases. We can not just "redo our
> implementation".  One of the things that''s bit me,
repeatedly, with
> Rails is that it makes dozens, if not hundreds of assumptions, about
> how things should work.  This makes for an amazingly fast development
> cycle when Rails is driving development, and when we can control
> things that way.
> 
> When, instead, we are retrofiting the framework onto something already
> in place, it blows up all over the place.  I''ve started
documenting
> some of those, but it would be nice if those "assumptions" (like
> pluralizations) could simply be turned off when appropriate.  That
> would make Rails substantially more usable for existing applications,
> rather than having to fight against it constantly.
> 
> Having said that, it''s still an impressive framework, I just want
it
> to be better.
> 
> Chris
> --
> | Christopher Petrilli
> | petrilli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Christopher Petrilli <petrilli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
writes:
> On 7/10/05, Doug Alcorn
<doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org> wrote:
>> Rails is "convention over configuration".  The idea is to
learn the
>> convention and make your life simpler.  If he redid his implementation
>> with the proper class/table name his problem would have come out in
>> the wash.
>
> As someone new to rails, I''m going to have to disagree with
> this. Some of us are glueing rails onto existing database schemas
> that have "aged" over decades in some cases. We can not just
"redo
> our implementation".
I''ll plead "don''t shoot the messenger" here.  I
think it''s well known
that Rails doesn''t play nice with "legacy" databases.  AFAIK,
one of
the design parameters (assumptions) with Rails at this point is that
it''s only used for new projects.  I''m not a core team member
and I
don''t have CVS write access.  I''m not DHH; nor have I ever
actually
spoken with him.  He could come in here and say, "Rails is meant to be
a revolutionary framework to save the masses of folks with
complicated, legacy databases from the mindless work of CRUD." 
I''ve
only given my opinion of what I''ve understood from reading this
mailing list and the Rails book.

Without Dave''s explicit permission, here''s a quote from the
Introduction of the Rails book:

   Convention over configuration is a crucial principle, too. It means
   that Rails has sensible defaults for just about every aspect of
   knitting together your application. If you follow the conventions,
   you can write a Rails application using fewer lines of code than a
   typical Java web application uses in XML configuration files. If
   you need to override the conventions, Rails makes that easy, too.

We could debate that last sentence.  Personally, I think it''s a bit
optimistic to think you can easily override the pluralization
assumptions.  There are lots of places it jumps up to bite you.
Pluralization has been debated here several times.  I don''t really
want to start another debate on the merits of pluralization versus
not.  

I might agree with you that a single switch for "turn off
pluralization everywhere" would be nice for those of you with existing
database designs.  I can''t fathom the size of such a patch though.  A
quick grep through the source code for ActionMailer, ActionPack,
ActiveRecord, and Rails for 0.12 only shows 35 hits on the word
''plural''.

This thread started with someone not following the convention of
database table names pluralized.  I assumed this was a new project.  I
assumed he could most easily fix his problem by following the
convention.  What I didn''t do was explain my answer.  I tersely said
something like "rename your table and it''ll work".  I should
have
given more explanation as to why I was recommending that.
-- 
doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org

I''m taking the liberty of renaming this thread. which was "[Rails]
Table
called ''lens'', won''t work.."

I certainly agree with the comments of Chris Petrelli (at the bottom of this
email).  First impressions of Rails are that it is an awesome framework but
simply not suitable for applications where you don''t have the freedom
to
completely control all database structures and "do it the rails way". 
This
means that Rails is unsuitable for the vast majority of "serious"
development work which almost always (IMO) involves connecting to some sort
of legacy system.  Greenfields projects are rare.

HOWEVER - I''m not quite convinced that my first impressions are
correct.  I
suspect that Rails does actually fairly easily allow you to override all its
assumptions and "holier than thou" attitude about how databases should
be
structured, and it certainly allows switching off of pluralisation.  The
question is how much of the rest of it breaks when pluralisation is turned
off.

SO - I''ve decided to learn Rails in order to provide myself wrong.  I
would
like to eventually be able to say "no, Rails is easily adaptable to legacy
databases, it''s just that all of the documentation and developer
communication seems to indicate that it''s "Rails Way Or No Way At
All".  The
best way to comment on these things is from a position of geniune
understanding of Rails, which I do not yet have.

IF it''s true that Rails can fairly easily be adapted to work with any
database structure them it''s a pity that this is not sold up front as a
key
benefit/feature.

I think I''ll never be convinced that pluralisation is a good idea - for
a
number of reasons.  Apart from pluralisation, Rails is generally super
intuitive and it "thinks the way you do".  Pluralisation is the
opposite of
this - deeply unintuitive.  IMO the english language has no place in
computer programming and deeply integrating english into a development
framework is simply a bad idea.  Even worse is integrating the english
language into database structures.  The english language is riddled with
pluralisation exceptions and idiosyncracies that can only serve to increase
complexity.  A major problem is that English language is not the first
language of many computer programmers.  English is my first language and I
find it deeply unintuitive to have to deal with pluralisation in Rails - it
must be much worse for programmers who have a different first language -
yeah I know that DHH is from Denmark or somewhere similar but many Europeans
speak english better than the english.  Also there are many many many items
of data that simply are not english language "things with a plural"
and the
whole system is pointless from this persepctive.  Apart from anything, I
simply don''t want my databases to be structured in that way.  I suspect
many
with an enterprise development/enterprise database background will raise an
eyebrow when they hear  about the impositition of plurlisation on database
and application structure.  BUT ONCE MORE I am trying to learn Rails to see
if my prejudices might be wrong about pluralisation - I''m willing to be
converted but it seems unlikely that I will be.

Personally I think pluralisation should be cut out of the framework and
ditched for future releases and replaced with a better way of handling
legacy systems.  But every new technology has its dogma and it take a new
technology to replace the old one without the dogma for things to change.
Until then, Rails is the simplest game in town for web development and very
very nicely designed - in fact a work of genius, but a genius who has never
worked at a bank.

Just my 10cents.  I''ll rewrite my opinions after I''ve learned
Rails in
enough depth.  I want to believe.

Andrew

Chris Petrelli wrote:
"""As someone new to rails, I''m going to have to
disagree with this. Some
of us are glueing rails onto existing database schemas that have
"aged" over decades in some cases. We can not just "redo our
implementation".  One of the things that''s bit me, repeatedly,
with
Rails is that it makes dozens, if not hundreds of assumptions, about
how things should work.  This makes for an amazingly fast development
cycle when Rails is driving development, and when we can control
things that way.

When, instead, we are retrofiting the framework onto something already
in place, it blows up all over the place.  I''ve started documenting
some of those, but it would be nice if those "assumptions" (like
pluralizations) could simply be turned off when appropriate.  That
would make Rails substantially more usable for existing applications,
rather than having to fight against it constantly.

Having said that, it''s still an impressive framework, I just want it
to be better."""

On 7/10/05, Andrew Stuart
<andrew.stuart-TWq/lk6o2i4FZYWR8B6FNDvXrrhHudLZEK66K81epY8@public.gmane.org>
wrote:
> I think I''ll never be convinced that pluralisation is a good idea
- for a
> number of reasons.  
You can disable pluralization by inserting one statement into the code:
ActiveRecord::Base.pluralize_table_names = false

Also, see http://wiki.rubyonrails.com/rails/show/HowToUseLegacySchemas

On 7/10/05, Doug Alcorn <doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org>
wrote:
> I might agree with you that a single switch for "turn off
> pluralization everywhere" would be nice for those of you with existing
> database designs.  I can''t fathom the size of such a patch though.
A
> quick grep through the source code for ActionMailer, ActionPack,
> ActiveRecord, and Rails for 0.12 only shows 35 hits on the word
> ''plural''.
ActiveRecord::Base.pluralize_table_names = false

On Mon, 2005-07-11 at 11:06 +1000, Andrew Stuart wrote:
> HOWEVER - I''m not quite convinced that my first impressions are
correct.  I
> suspect that Rails does actually fairly easily allow you to override all
its
> assumptions and "holier than thou" attitude about how databases
should be
> structured, and it certainly allows switching off of pluralisation.  The
> question is how much of the rest of it breaks when pluralisation is turned
> off.
I think that this is the ''wrong'' way to look at this Andrew.

When you use the built-in switches to override the default framework
behavior, nothing is supposed to ''break.'' You are simply
''choosing'' to
give up some of the rails goodness that many of the object methods
provide, and having to ''roll-your-own'', so to speak.
Everything that the
automagical methods do, AFAIK, can be done ''the hard way'',
when
necessary (e.g. when working with a legacy system). True, alot of the
''Rapid Development'' aspect that makes Rails so sweet
''goes away'', but
you still have a framework that is, IMHO, much better than the
alternatives. 
> SO - I''ve decided to learn Rails in order to provide myself wrong.
Whatever your motivation, learning Rails is never a bad thing -- 
You''ll probably just have to learn ''alot more of it''
in order to
routinely work with legacy systems :)

> I think I''ll never be convinced that pluralisation is a good idea
- for a
> number of reasons. 
Then turn it off:

ActiveRecord::Base.pluralize_table_names = false

Also, Joe''s wiki link is there for you and anyone else who
doesn''t
have control over the schema

But the biggest error you''re making is confusing Rails the full
framework with ActiveRecord the ORM.   You can easily create a rails
app which doesn''t use active record (see instiki as an example) and up
until recently, all my rails development was like this.  You can build
your own persistence framework which makes direct calls to the
ruby-dbi where required.  It can call stored procedures,  do HTTP
POSTs, SMS the tooth fairy.  Whatever you want.

Just like you would in any other programming environment.   Use DAOs
or whatever other persistence approach you''d normally use.

Yes, active record can''t handle as many corner cases as a full ORM
tool like hibernate can,  but this is a feature!   Pushing AR much
further would rapidly pass the point of diminishing marginal returns
and we''d have 4000 lines of XML,  fancy build systems required etc.
etc. etc.

-- 
Cheers

Koz

Joe Van Dyk wrote:
>On 7/10/05, Doug Alcorn <doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org>
wrote:
>
>  
>
>>I might agree with you that a single switch for "turn off
>>pluralization everywhere" would be nice for those of you with
existing
>>database designs.  I can''t fathom the size of such a patch
though.  A
>>quick grep through the source code for ActionMailer, ActionPack,
>>ActiveRecord, and Rails for 0.12 only shows 35 hits on the word
>>''plural''.
>>    
>>
>
>ActiveRecord::Base.pluralize_table_names = false
>  
>
I had this in environment.rb, and it had no effect, for this particular 
problem.

    -klm.

> I had this in environment.rb, and it had no effect, for this particular
> problem.
It won''t work with the scaffolding generator.   This is a known issue
and will not be fixed till after rails 1.0.



-- 
Cheers

Koz

Doug Alcorn wrote:
>Jason Foreman <threeve.org-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
writes:
>
>  
>
>>While I do agree with the idea of having pluralized table names,
>>this is a totally bogus response to Ken''s question...
>>    
>>
>
>No, it''s not.  His problem was that AR (or specifically paginate)
>improperly guessed the proper class name based -- as you pointed out
>in his message.
>
>Rails is "convention over configuration".  The idea is to learn
the
>convention and make your life simpler.  If he redid his implementation
>with the proper class/table name his problem would have come out in
>the wash.
>  
>
Well, I will say that in this case, it is possible to re-do the 
implementation, since it''s new development.  However, my original 
question was why, when I explicity disabled pluralization, was I not 
able to access the ''lens'' table?  I thought I was missing a
bit of
''scaffolding'' between the database and the model - your answer
was not
useful in this respect.

Instead of fighting with the issue, I''ll probably just re-do the 
implementation.  In other words, I''ll make my foot fit the shoe instead
of the other way around.

But, please keep in mind that I may have been working with a legacy 
database schema, where I may not have had the ability to alter the 
structure in any way.

Peace.

    -klm.
>Yes, he can override the defaults and make this particular problem go
>away.  And the next one, he''ll have to another override, and
another.
>Or he can choose to follow the Rails convention and the rest will be
>smoother.
>
>  
>
>>On 7/10/05, Doug Alcorn
<doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org> wrote:
>>    
>>
>>>Ken Miller
<klm-qD6opK7ZJR2ttCpgsWEBFlaTQe2KTcn/@public.gmane.org> writes:
>>>
>>>      
>>>
>>>>First off, I name my database tables for the type of object that
>>>>they contains, which implies no pluralization.  I have a
database
>>>>table called ''Lens'', for camera lenses.  When
I execute this
>>>>command:
>>>>        
>>>>
>>>Table names are supposed to be plural.  Name you table
''lenses''.
>>>      
>>>
>
>  
>

> Well, I will say that in this case, it is possible to re-do the
> implementation, since it''s new development.  However, my original
> question was why, when I explicity disabled pluralization, was I not
> able to access the ''lens'' table?  I thought I was missing
a bit of
> ''scaffolding'' between the database and the model - your
answer was not
> useful in this respect.
I should expand on my earlier comments.

If you''re using scaffolding and you have a custom table name,  you
should use the reflection based scaffolding,  i.e

ruby script/generate model  SomeModel
ruby script/generate controller SomeController

then in some_controller.rb add

scaffold :some_model

This will work fine.  It''s two more steps than the scaffold generator,
and you don''t get the files on disk.  However,  scaffolding is only a
starting point.  It''s not meant to be a full application framework

-- 
Cheers

Koz

Hi,

We are having the same troubles with a legacy postgresql db here. The best way 
to deal with it is to use :foreign_key and :association_foreign_key in the 
associations (has_many and the like), set_table_name and set_primary_key in 
every model, this way nothing has to be guessed by rails. It''s not that
much
extra work after all.

With the changes in 0.13 this works pretty well now.

regards,
Bas


Christopher Petrilli wrote:
> On 7/10/05, Doug Alcorn
<doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org> wrote:
> 
>>Rails is "convention over configuration".  The idea is to
learn the
>>convention and make your life simpler.  If he redid his implementation
>>with the proper class/table name his problem would have come out in
>>the wash.
> 
> 
> As someone new to rails, I''m going to have to disagree with this.
Some
> of us are glueing rails onto existing database schemas that have
> "aged" over decades in some cases. We can not just "redo our
> implementation".  One of the things that''s bit me,
repeatedly, with
> Rails is that it makes dozens, if not hundreds of assumptions, about
> how things should work.  This makes for an amazingly fast development
> cycle when Rails is driving development, and when we can control
> things that way.
> 
> When, instead, we are retrofiting the framework onto something already
> in place, it blows up all over the place.  I''ve started
documenting
> some of those, but it would be nice if those "assumptions" (like
> pluralizations) could simply be turned off when appropriate.  That
> would make Rails substantially more usable for existing applications,
> rather than having to fight against it constantly.
> 
> Having said that, it''s still an impressive framework, I just want
it
> to be better.
> 
> Chris

On 7/10/05, Joe Van Dyk
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 7/10/05, Andrew Stuart
<andrew.stuart-TWq/lk6o2i4FZYWR8B6FNDvXrrhHudLZEK66K81epY8@public.gmane.org>
wrote:
> > I think I''ll never be convinced that pluralisation is a good
idea - for a
> > number of reasons.
> 
> You can disable pluralization by inserting one statement into the code:
> ActiveRecord::Base.pluralize_table_names = false
> 
> Also, see http://wiki.rubyonrails.com/rails/show/HowToUseLegacySchemas

IIRC, the OP noted that the generators do NOT respect this setting. (I
might be wrong on that,  mind you.)

Let''s assume that it''s true for a moment then; is it a bug? 
I''d argue "yes".

That said, I think the whole plurari{z,s}ation aspect is weird and
arbitrary for the sake of it, and causes many more problems than it,
well, "solves" isn''t even right... it causes more problems
than it''s
worth.  My $0.02, anyway.

> > You can disable pluralization by inserting one statement into the
code:
> > ActiveRecord::Base.pluralize_table_names = false
> >
> > Also, see http://wiki.rubyonrails.com/rails/show/HowToUseLegacySchemas
> 
> IIRC, the OP noted that the generators do NOT respect this setting. (I
> might be wrong on that,  mind you.)
> 
> Let''s assume that it''s true for a moment then; is it a
bug?  I''d argue "yes".
It is. There''s really no need to get on the barricades about it ;).
Rails will provide a golden path where everything is pre-configured
for you if you accept a number of conventions (pluralization is one of
them).

If you''re forced off the golden path by either legacy or idiosyncratic
concerns, it should still be possible to reach the destination. You''ll
just have to fight a little harder for it (which basically means you
have to do what you''ve always would have done in a non-convention
driven framework).

So. Please do make tickets if something unexpected blows up when
pluralization is turned off.
-- 
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework

I for one find it enlightening to remember that it took billions of  
dollars of R&D and many years of tweaking before EJB 3 <sarcasm>got  
it right</sarcasm>.  Even when I''m forced off the "golden
path" as
DHH puts it, I''m much happier with Rails than I was in EJB hell.

So lighten up everyone - it could be worst :)

On 11-Jul-05, at 9:13 AM, David Heinemeier Hansson wrote:
>>> You can disable pluralization by inserting one statement into the  
>>> code:
>>> ActiveRecord::Base.pluralize_table_names = false
>>>
>>> Also, see http://wiki.rubyonrails.com/rails/show/ 
>>> HowToUseLegacySchemas
>>>
>>
>> IIRC, the OP noted that the generators do NOT respect this  
>> setting. (I
>> might be wrong on that,  mind you.)
>>
>> Let''s assume that it''s true for a moment then; is it
a bug?  I''d
>> argue "yes".
>>
>
> It is. There''s really no need to get on the barricades about it
;).
> Rails will provide a golden path where everything is pre-configured
> for you if you accept a number of conventions (pluralization is one of
> them).
>
> If you''re forced off the golden path by either legacy or
idiosyncratic
> concerns, it should still be possible to reach the destination.
You''ll
> just have to fight a little harder for it (which basically means you
> have to do what you''ve always would have done in a non-convention
> driven framework).
>
> So. Please do make tickets if something unexpected blows up when
> pluralization is turned off.
> -- 
> David Heinemeier Hansson
> http://www.loudthinking.com -- Broadcasting Brain
> http://www.basecamphq.com   -- Online project management
> http://www.backpackit.com   -- Personal information manager
> http://www.rubyonrails.com  -- Web-application framework
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>