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:
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.
In your Elassandra support page, you have an example of mapping that uses
string
as a type and uses"analyzed"
for theindex
field:Newer versions of Elassandra changed
string
to eithertext
(searchable, equivalent tostring
+index: "analyzed"
) orkeyword
. 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: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 thediscover: ...
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.