Creating new types in 6.0

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?

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.

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.

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?

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).

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

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