No, it doesn't bother me. One of the main goals of RoR was to not repeat yourself. You already have the data model defined elsewhere; why define it again? It's in the migrations already, and via migrations, in the DB. There are plugins that will add comments to the AR class showing the fields as well.
There are any number of ways to get the fields without going to the DB, too; this is Ruby we're talking about.
I was just coming to this forum to ask about this. Right now, it bothers me. Probably because I'm used to seeing them in the model. Jumping around between files to remember what the properties seems a huge PITA for me. David, do you have links to the plugin you mentioned? Also, when you update a migrate script with new columns, does the plugin update the comments in the model?
It used to bother me when I was only used to editors like Eclipse and NetBeans.
If you're using Vim or Emacs, it's not too hard to set up a shortcut to jump to the appropriate area of your db/schema.rb file. For instance, using rails.vim (https://wincent.com/wiki/rails.vim_cheatsheet), I can be in the user.rb model and type :R Enter to jump to the users definition in the db/schema.rb and then hit g Enter to return to where I was in the user.rb model.
Having this in my tool belt I think it's significantly *better* to not cloud the models with attributes.
(Personally, I agree; I enjoyed having the definition of DB stuff in only one place (migrations, usually) and used other means to navigate. I didn't mind having the docs, but I rarely did that either--mostly when it was other people's model.)
Time for my 2 cents .
It does bother me but if you have a look at the code in the sample Depot Application for the models (generated by Netbeans) you can put nice annotated docs to suggest the fields (I believe the book "Agile Development with Rails" specifies more).
I got used to having the DB console open in the first stages of developing the application. Of course with Java/Hibernate things are not so bad but it's not a major block.
The fact that you can discover the error in an instant kind of compensates for this small annoyance.
This reminds me I should use that plugin for my current RoR code .
Better, faster, lighter Java ... you mean Ruby right ?
SCEA5,SCBCD1.3,SCWCD5,SCJP1.4 - memories from my youth.
I'm coming late to this discussion, but this has been on my mind lately as well...
I don't feel completely comfortable with Models in ActiveRecord either, for the same reasons mentioned by a few other posters above. A lot of this boils down to personal preferences and style - for me, the Model object is the foundation of how I think about code. I often think about a problem in terms of objects (which I'll admit isn't always the best approach), and when I start writing code, I often begin with the object model. ActiveRecord clearly takes a different approach that has proven to be immensely productive. However, I'd rather be able to define my objects more explicitly.
Do keep in mind that this is really about ActiveRecord, not rails per se. There's nothing really stopping you from writing your own object model and persistence tier in Rails if you want to do things differently. Another thing you might want to do is look into DataMapper, which is an alternative to ActiveRecord that would probably appeal to people who want more direct control over the model (check out datamapper.org).
That said, I haven't really used datamapper, mainly because in spite of what I wrote above, I'm willing to stick with ActiveRecord. I think I gain much more than I give up, and if I'm using Rails, it's probably because the rails conventions line up very nicely with my project. Keep in mind that a lot of extremely useful plugins also assume ActiveRecord. One of the things I like most about Rails is how easily everything seems to work with minimal configuration - in other words, I'm often willing to make a trade off to take advantage of Rails conventions, including ActiveRecord.
But yeah, for those of us who tend to think in objects (POJOs, for instance), it can be disconcerting to open up a model and see nothing there.