Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Elassandra Support Documentation says to use 'string' and 'index: "analyzed"' which is not available in newer versions of Elassandra #187

Open
AlexisWilke opened this issue Dec 5, 2018 · 0 comments

Comments

@AlexisWilke
Copy link
Contributor

AlexisWilke commented Dec 5, 2018

In your Elassandra support page, you have an example of mapping that uses string as a type and uses "analyzed" for the index field:

es_index_mapping: {
  discover: '.*',
  properties: {
      "name" : {
          "type" : "string",      // <- this is now wrong, should be `text` for this example
          "index" : "analyzed"    // <- this is now wrong, you may use `index: true`, although type `text` is probably enough
      }
  }
}

Newer versions of Elassandra changed string to either text (searchable, equivalent to string + index: "analyzed") or keyword. So we should probably change that.

Further, the new system will fail with an error saying that there is a type mismatch between the given type (text) and the inferred type (list<text>), which is due to the fact that by default fields are viewed as collections. To palliate you need to use the CQL collection parameter like this:

  properties: {
      "name" : {
          "type" : "text",
          "index" : true,
          "cql_collection" : "singleton"
      }
  }

This is probably since Elassandra version 5.x, for sure, 6.x requires such.

Finally, I had a problem with the concept of "To overwrite some properties, you could do the following:" — somehow that does NOT work, at least not for for text fields. So what I had to do with Elassandra 6.2.3.7 is add every single type definition manually and not use the discover: ... at all. I will probably be testing some more to see whether I could use a different pattern than ".*" to include fields that can automatically be generated and use specific field definitions for the rest. But overwrite is apparently the wrong word with the latest version, unfortunately. I'll post a bug report for that problem in Elassandra and see what they have to say about this. It may also be a problem in ElasticSearch itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant