Possible to have optional _parent field in future?


(James Addison) #1

Would it ever be feasible to have a parent/child relationship where the child mapping's _parent field was optional? Last time I tried it, the results weren't pretty.

I have this exactly scenario, where it's possible to have a child document without a matching parent document - we treat them somewhat differently in our product, but they're still valid to us.

To achieve this currently, I'm forced to have a separate document type for the parent/child specific documents and another for everything, resulting in having to index documents twice - one for each of the two types.

Is this possible to achieve in future releases? Thanks
James


Are parents required with join fields?
(Adrien Grand) #2

Maybe you could use a fake parent document for these orphan documents?


(James Addison) #3

Ewww! I suppose faking a parent could work, but it's such a hack. Are optional parents going to be possible in future? Or is this use case completely ridiculous?


(Martijn Van Groningen) #4

The reason why your need to define a parent when indexing a child type is because it is used for routing. ES routes the parent and child docs into the same shard.

I don't fully understand why you need to to index all your documents twice. A document either is a child of a parent or isn't a child of a parent. Can you maybe explain a bit more why you're doing this?

I think we can change the indexing of a child document, so that it also accepts a null parent and then it is an orphan child. But if these orphan child docs ever need to be associated with a parent, it first needs to be deleted and then indexed again. (the update api won't work, because the parent maybe in a different shard)


(James Addison) #5

The reason is simple (to me, at least) - sometimes we have orphaned child documents, and this is valid in our system. Ideally parents would always be set, but given the nature of the problem we're solving, our data inputs don't always have parents. But orphan child documents are still useful and valid in our product.

You explain the routing problems associated with switching from orphaned to parented well - in particular the update API concern. I hadn't thought of such complications.

I know we would truly benefit from the optional parent mapping, but it does present problems to which I wish I had the answers...


(system) #6