Comments for lifo's docrails  

Thanks for the code examples!

The information added here would have hastened the discovery of why tables were "mysteriously" reappearing in my db/schema.rb file when I thought they’d been removed previously.
It’s a bit tricky working with multiple developers on different git branches. If you use rake db:schema:load in development instead of always running migrations, you may end up with supposedly dropped tables reappearing in your db/schema.rb.
For example:
- Bill created a table called "jobs" a few months ago
- Bob changed background processing plugins and dropped the "jobs" table in a migration
- Bob merges his code into master
- Bill grabs the latest master and runs rake db:shema:load
- Bill doesn’t see a "jobs" table in his schema, but the table was never dropped from his development database, so it’s still there
- Bill creates a new migration and runs rake db:migrate, which also invokes the db:schema:dump task
- Bill has added the "jobs" table back to db/schema.rb
- Bill is confused :)
Apologies for the long comment – I just wanted to explain why I’m trying to clarify what happens when you run rake db:migrate. It sure confused me at first!

Oops..be careful with those :)

Looks like you are right bensie, thanks for the good find.

Not sure your description of created_at vs. created_on or updated_at vs. updated_ on are correct. I always use created_at and updated_at (as does the t.timestamps in migrations), and it stores the full current date and time.

Awesome stuff Hongli :)

If https://rails.lighthouseapp.com/projects/8994/tickets/865-fix-count_records#ticket-865-2 gets applied and merged back I will revise the last paragraph.

Strange, If I try generate admin/controller, this message apears:
$ sg controller ‘admin/categories’
The name ‘Admin::CategoriesHelper’ is either already used in your application or reserved by Ruby on Rails.
Please choose an alternative and run this generator again.
But I only have CategoriesHelper, not "Admin::CategoriesHelper".

Why exactly?
What does this mean in context of: https://ola-bini.blogspot.com/2008/05/dynamically-created-methods-in-ruby.html

Michael—nicely done here.

I think this behaviour is not consistent, but a patch could break backwards compat. So at least we document it.

Woah I didn’t know it was a RDoc gotcha! Always thought there was some other meaning (that was unclear to me). Now I know, thanks!

Done! I start to feel the wiki needs a bit more of structure, but let’s see how it works.

Heh, a missing LT TT GT there as well :-)

That’s a good idea. The conventions are evolving as needed and I think it would be good to add a section about rdoc gotchas. The + versus <tt> is a good tip for sure.

Oops I meant to say &lt;tt&gt;

Thanks Xavier :) I was wondering what to do with the ’+’s for class names.
Was trying to look for conventions on when to use <tt> and when to use + in the wiki – maybe you could write that down too? Thanks!

Oh sure, I think we could standarize for all lists like those ones. I’ll revise the wiki. Indeed in this case they aren’t really options, "=== Parameters" would be certainly better.

Sure! However these "Options" are actually lists of parameters and not hashes of options. Do the same rules apply?
Perhaps these lists should be renamed to "=== Parameters" instead…

Hi there! I wrote some conventions for lists of options in the wiki just yesterday. If they are OK for you could you please revisit those docs following them?