Some notes on Naming #277

amrnt opened this Issue Mar 14, 2012 · 7 comments


None yet

3 participants


I'm trying Tire now on some project. While I was making some tests I found some issues with STI at all!

Also, I found a bug in naming document_type and I think it should be without singuler

1.9.2p290 :161 > Link.model_name.singular
 => "link" 
1.9.2p290 :162 > Link::Google.model_name.singular
 => "link_google" 

somehow i have some associations..

NameError: You have tried to eager load the model instances, but Tire cannot find the model class 'LinkGoogle' based on _type 'link_google'.

which all of above class didnt exist!

If you have any trick or tip please forward it to me.


Hi, unfortunately these are known bugs, see issues #218, #204, etc. The issue is caused by incorrect serializing of document_type. It is a priority bug right now.



Though, I want to discuss on how we would search STI models.

Let's say I have Link model and a subclass Link::Google < Link.

We have to main method to focus on, index_name and document_type. Actually, I'm not sure how they work and being set in Tire (I've not trace the source yet). But I think the best way for that is:

  • For both models since the super class is Link the index_name in both cases should be links (by defauls)
  • For Link model, document_type should be Link as it, since type or _type will be nil. For subclasses, ie Link::Google should be as , since AR > 3 saves the type as the class name -I'm not sure how it saved in other ORM or ODM-

After all, when you search via Link (the super class) it must return all the results from across the subclasses models attached with the model type.


Notice that my subclass model is namespaced. Translating Link::Google to link_google doesn't make sense since LinkGoogle could be translated to link_google


Once the bugs are smashed, it should serialize the document types as follow, AFAIK:

  • Link => link

  • LinkGoogle => link_google

  • Link::Google => link/google, URL encoded as link%2Fgoogle

This part of ActiveModel is the underlying cause, AFAIK.


Let me know: when I index Link model, the whole table will be indexed, right?

if the method is in Link, will the search return results from subclasses? If no as I see, how I could return them... notice that index_name will be links... but the type is different!


There was some discussion on IRC today about that...

If you're not interested in :load-ing the models, you can make all the document_types to return the same value...

when I index Link model, the whole table will be indexed, right

Depends on lots of things. When you use the bundled import, only the class you pass is used.

if the method is in Link, will the search return results from subclasses

Again depends on lots of things. Try to gist some code maybe....

@karmi karmi added a commit that closed this issue Mar 22, 2012
@karmi [#218] Cleaned up the codebase for loading instances of multiple clas…
…ses / single table inheritance

Previously, eagerly loading instances of multiple classes with the `load: true` option was not possible.

Now, you can use the `` DSL for searching and loading multiple models from one or several indices:

    ActiveRecordModelOne.create :title => 'Title One', timestamp:

    s = ['active_record_model_one', 'active_record_model_two'], :load => true do
                  query { string 'title' }
                  sort  { by :timestamp }

    puts s.results[0].inspect
    # => <ActiveRecordModelOne id: 1, title: "Title One", timestamp: "1332437294">

Fixed indentation/formatting/whitespace throughout the suite :/

Fixes #80, fixes #178, fixes #218, fixes #277, closes #131.
@karmi karmi closed this in d5c08fb Mar 22, 2012

Is setting document_type the same for the parent class and all subclasses still the best option? I want to search the parent class and have it return listings in the subclasses. If I set document_type on all the subclasses, my tests pass as expected. If I remove the explicit document_type, tests fail to find results requiring filters and I'm not sure why.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment