4 ms·

Thing is the parent/child functionality required using multiple types in single index. So migrating from that is painful.

by ergo14 9y ago

yehosef 9y ago
They are supposed to implement it using a join field - but it's not as nice as it is now (AFAIK you can't have multiple join types.. eg, I can't have grandchildren or two different kinds of children). It's really unfortunate because the issues they had with multiple types could have been handled more elegantly and still kept the immense power of parent-child fields. It feels from the discussion of the github issues that this was something that had caused some elastic developers pain and they decided to kill it.
- ergo14 9y ago
  The way it will be handled from 6.x forward is better - the problem is, this will be tricky to migrate from older versions.
  - yehosef 9y ago
    The 6 way is maybe better than the 5.x way - but there are problems with it and they could have done the 6.x better than they did. There were two fundamental problems: 1) types had different mappings which was confusing since internally it's the same index and there is only one mapping. 2) for the use case where you have one type per index, you still had to arbitrarily create a "type". It could have been done by: 1) making the mapping definition only at the index level - there's no such thing as a mapping for a type (this is how it works internally anyway.) 2) with a "type" field being optional and specified via a query string instead of url path. This would have left all the internals alone. Eg, there could have still be an internal meta "_type" field which would have had the default value of "default" or something. For those people that needed multiple types, specifically for more complex parent-child, they still could have done it. The current approach is far more complicated because the have to change the internals to support both the new and old way during the transition and deal with a lot of internal things breaking because everything expects a "_type". You can checkout the github issues and see the work involved.
  - yehosef 9y ago
    I detailed some of my issues/suggestion at https://discuss.elastic.co/t/parent-child-and-elastic-6/85722/5 https://discuss.elastic.co/t/parent-child-and-elastic-6/8572... but to no avail. After I looked through some of the github issues, I realized how long this was in the pipeline for and how much inertia there was in the direction.

Thing is the parent/child functionality required using multiple types in single index. So migrating from that is painful.

by ergo14 9y ago

Thing is the parent/child functionality required using multiple types in single index. So migrating from that is painful.

yehosef 9y ago

They are supposed to implement it using a join field - but it's not as nice as it is now (AFAIK you can't have multiple join types.. eg, I can't have grandchildren or two different kinds of children). It's really unfortunate because the issues they had with multiple types could have been handled more elegantly and still kept the immense power of parent-child fields. It feels from the discussion of the github issues that this was something that had caused some elastic developers pain and they decided to kill it.

ergo14 9y ago
The way it will be handled from 6.x forward is better - the problem is, this will be tricky to migrate from older versions.
- yehosef 9y ago
  The 6 way is maybe better than the 5.x way - but there are problems with it and they could have done the 6.x better than they did. There were two fundamental problems: 1) types had different mappings which was confusing since internally it's the same index and there is only one mapping. 2) for the use case where you have one type per index, you still had to arbitrarily create a "type". It could have been done by: 1) making the mapping definition only at the index level - there's no such thing as a mapping for a type (this is how it works internally anyway.) 2) with a "type" field being optional and specified via a query string instead of url path. This would have left all the internals alone. Eg, there could have still be an internal meta "_type" field which would have had the default value of "default" or something. For those people that needed multiple types, specifically for more complex parent-child, they still could have done it. The current approach is far more complicated because the have to change the internals to support both the new and old way during the transition and deal with a lot of internal things breaking because everything expects a "_type". You can checkout the github issues and see the work involved.
- yehosef 9y ago
  I detailed some of my issues/suggestion at https://discuss.elastic.co/t/parent-child-and-elastic-6/85722/5 https://discuss.elastic.co/t/parent-child-and-elastic-6/8572... but to no avail. After I looked through some of the github issues, I realized how long this was in the pipeline for and how much inertia there was in the direction.