_type mangling on record after #update_index #271

Closed
demersus opened this Issue Mar 9, 2012 · 3 comments

Comments

Projects
None yet
2 participants

demersus commented Mar 9, 2012

I am using Mongoid as my ODM. I am also using single collection inheritance. Tire wants to put all of my sub classes into the same elastic search type.

Example:
I have a class type of Foo,
When I have a sub class of Bar, tire wants to put all 'bars' in elastic search as 'foos'.

I noticed a method named .document_type, which will allow me to change what elastic search '_type' I want. In my 'Bar' model I do this:

document_type 'bar'

If I call '#update_index' on my bar model, it will set the actual _type field on my mongoid instance to 'bar'. It should be 'Foo::Bar'. If I save my model afterwards to the database, it will save the _type field as 'bar'. Is this the intended behavior of '.document_type' ?

Owner

karmi commented Mar 9, 2012

Hi, it's a known bug, there are several issues opened for that: #265, #201 related to that. It needs to be solved, definitely. And it needs to be solved with the multimodel search bug, #218 looks very promising in this regard.

demersus commented Mar 9, 2012

I don't know that those issues directly solve the one I am experiencing. However they do address the root issue why I started playing around with the document_type settings. I don't think update_index should be able to over write any model attributes. At least not any that could potentially be persisted to the database after a manual index update.

Thank you for your huge contribution to the community with Tire. I understand I am complaining without offering solutions. So I will take a stab at a solution when I have some time.

#218 does look like a good solution to the multi model issue. Is there something holding you back from pulling that fix into master?

Owner

karmi commented Mar 10, 2012

Is there something holding you back from pulling that fix into master?

Time :) (Joking.) Seriously, I need to review all the patches related to this issue, and somehow kill it in one swoop. I got burned with some commits such as 1d6b267 and am a bit reluctant to "just pull" on a piece-by-piece basis now, usually pulling the patch means making sure it still makes sense in the grand picture....

karmi closed this in 26f01b0 Mar 22, 2012

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