Here's the scenario. Imagine three classes like this in a Rails app:

class Post; end
class Article < Post; end
class Image < Post; end

If the DB contains data that looks like this in the posts table:

id | title      | type
 1 | An article | Article
 2 | An image   | Image

Then this works great:

post = Post.find(1)
puts post.class           #Article
puts post.decorate.class  #ArticleDecorator

However, the following does not work so well (assuming Post.published returns a query):

posts = Post.published.decorate
puts posts.map { |p| p.class } #[PostDecorator, PostDecorator]

My expectation would be that the classes returned when decorate is called on a collection would be:

[ArticleDecorator, ImageDecorator]

But, it doesn't. I assume I'm not missing something obvious, but might be.

Assuming this isn't operator error on my part, it seems the easy way to fix this would be to always defer to the item's decorate method. That may or may not be performant. One thing that could be done to see if deferring to item decoration is necessary would be to do a test like this:

Post.column_names.include? Post.inheritance_column

That would, in the case of the Post class, tell you if it was set up for STI or not.That might be premature optimization or there might be an easier or more general way to see if subclassing is a factor.

Is there any code in the works to address this? If not, I'm happy to write it myself and issue the pull request, but a brain dump would be appreciated to make sure I have as much context as possible.

BTW, awesome gem.