Creating new types in 6.0

Elastic Stack Elasticsearch
1

I can appreciate the decision to remove mapping types going forward in ES, I can also appreciate that version 6 has support for existing indexes with types, but we have until version 7 to totally remove the types.

As I understand it, I can force version 6 behavior in 5.6 with index.mapping.single_type: true, BUT I cannot do the opposite -- have version 6 allow multiple types with index.mapping.single_type: false.

My reality is I am stuck on 5.6 with multiple types and I don't feel I can risk running 6 without the ability to re-create/re-load existing typed indexes if I need to. Is there any way to do this in 6?

2

You can update to 6.0 even if your existing indices have multiple types. But you can’t create a new index in 6.0 with multiple types.

3

That confirms what I already knew. My dilemma is that the maintenance of the various systems I have using ES sometimes requires a re-index or otherwise dump/reload type rebuild of an index. This could be due to the need to patch in some new requirement, or tweak a mapping definition. This generally means needing to create a new index.

I have a big backlog of development effort to update these systems to be typeless, so if I go to 6, I'm essentially handcuffing my ability to maintain my existing systems, and that is unfortunately not an acceptable risk.

I personally feel you guys made a mistake in totally and absolutely preventing new indexes in 6 without types.

4

I personally feel you guys made a mistake in totally and absolutely preventing new indexes in 6 without types.

If multiple types is what you want, why not still keep 5.6 then?
And switch later to 6.x only when you are ready.

Because if such a switch was existing in 6.0, you'd probably use it and then complain later when 7.0 is released, no? I don't understand what'd be the difference TBH.

What do you have in mind?

5

I'm sure I should have paid more attention to the 6.0 dev cycle, so I can understand this is on me. That said, I'm here plodding along on 5.x and suddenly the next major release won't support a lot of what I spent the last year building.

For a datastore that people use for a lot of production data I would have expected something like:

5.x - opt-in to new behavior
6.x - opt-out of new behavior
7.x - the new behavior no matter what

True opt-out in 6.x would tell me (with hopefully plenty of time) that how I'm doing things is getting phased out, but does so in a way that doesn't bring my upgrades to a screeching halt.

5.x got opt-in a mere 2 months before 6 got released. 6.x is not opt-out because I cannot reproduce key functionality that I can with 5.x. If I were try to go to ES6 with typed indexes, I'd have to rebuild my testing framework to first create a fresh index on 5.6, do a 6.0 upgrade and then run my tests.

Further, types are more than just a "functionality" change, this is fundamental to the structure of ES from (I think) the beginning. I expect a production worthy datastore to support legacy behavior and phase it out in a more controlled way over a much longer period of time. I guess that's most of what irks me.

I can stay on 5.6 and probably will be forced to for a while. However, this means I'm going to fall even further behind in ES changes. It means I can't use any other new ELK features or fixes (Kibana 5.6 has a bug for me that is fixed in 6, but I have to use 5.5 instead).

6

In case you need more information about the full plan regarding this topic, it's there.

7

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.