Releases: siddhi-io/siddhi-store-elasticsearch
Siddhi Store Elasticsearch 3.2.2 Release
What's Changed
- Bump elasticsearch and log4j versions by @senthuran16 in #59
New Contributors
- @senthuran16 made their first contribution in #59
Full Changelog: v3.2.1...v3.2.2
Contributors
Assets 2
Siddhi Store Elasticsearch 3.2.1 Release
Siddhi Store Elasticsearch 3.2.0 Release
This Release is compatible with Siddhi 5.x.x
Overview
Siddhi Store Elasticsearch 3.2.0 release introduces support to add custom JSON documents into elasticsearch indexes
Highlights
- Support to add custom JSON documents into elasticsearch indexes. Implemented a sink for Elasticsearch to support this (#41)
@sink(type = 'elasticsearch', host = '172.17.0.2', port = '9200',
index.name = 'stock_index',
@map(type = 'json',
@payload(""" {
"StockData":{
"Symbol":"{{symbol}}",
"Price":{{price}},
"Volume":{{volume}}
}
} """)))
define stream stock_stream(symbol string, price float, volume long);
Complete Changes
Please find the complete changes here
Download
Download the release from here
Siddhi Store Elasticsearch 3.1.2 Release
This Release is compatible with Siddhi 5.x.x
Overview
Siddhi Store Elasticsearch 3.1.2 release contains bug fixes, documentation updates and Siddhi dependency upgrade to 5.1.5.
Bug Fixes
- Log4j dependency issues in startup (#39)
- Handling issues when index name provided in upper case (#39)
- Refactor documentation examples (#37)
Complete Changes
Please find the complete changes here
Download
Download the release from here
Siddhi Store Elasticsearch 3.1.1 Release
This Release is compatible with Siddhi 5.x.x
Overview
Siddhi Store Elasticsearch 3.1.1 release contains improvements related to backoff retry logic.
Features & Improvements
- Add backoff retry policy. (#33)
Change retry timeouts to connect to ES if any connection related exceptions
Bug Fixes
No Bug Fixes
Complete Changes
Please find the complete changes here
Download
Download the release from here
Siddhi Store Elasticsearch 3.1.0 Release
This Release is compatible with Siddhi 5.x.x
Overview
Siddhi Store Elasticsearch 3.1.0 release contains some improvements related to type mapping support and bug fixes.
Highlights
- In this release introduces a new annotation called TypeMappings. Please refer example config below:
@Store(type="elasticsearch", @TypeMappings(requestTimestamp="date", latitude="geo_point", longitude="geo_point"), elasticsearch.member.list="http://localhost:9200",username="elastic", password="changeme", bulk.actions="10000", bulk.size="5")
define table ESTable (meta_clientType string, requestTimestamp long, latitude double, longitude double);
Here we can specify the list of type mappings.
In this example config, 'requestTimestamp' attribute is mapped to type 'date', 'latitude' attribute is being mapped to type 'geo_point' and so on.
Note:
If above annotation is used then need to re-index all the existing data after updating the mapping type. Otherwise we would see the following warning in Kibana when we try to update the index pattern.
"Mapping conflict . A field is defined as several types (string, integer, etc) across the indices that match this pattern. You may still be able to use these conflict fields in parts of Kibana, but they will be unavailable for functions that require Kibana to know their type. Correcting this issue will require reindexing your data."
Bug Fixes
createIndex()method fails withElasticsearchStatusException(#23)- Fix indexname validations when creating index (#25)
Complete Changes
Please find the complete changes here
Siddhi Store Elasticsearch 2.1.0 Release
In this release introduces a new annotation called TypeMappings. Please refer example config below:
@Store(type="elasticsearch", @TypeMappings(requestTimestamp="date", latitude="geo_point", longitude="geo_point"), elasticsearch.member.list="http://localhost:9200",username="elastic", password="changeme", bulk.actions="10000", bulk.size="5")
define table ESTable (meta_clientType string, requestTimestamp long, latitude double, longitude double);
Here we can specify the list of type mappings.
In this example config, 'requestTimestamp' attribute is mapped to type 'date', 'latitude' attribute is being mapped to type 'geo_point' and so on.
Note:
If above annotation is used then need to re-index all the existing data after updating the mapping type. Otherwise we would see the following warning in Kibana when we try to update the index pattern.
"Mapping conflict . A field is defined as several types (string, integer, etc) across the indices that match this pattern. You may still be able to use these conflict fields in parts of Kibana, but they will be unavailable for functions that require Kibana to know their type. Correcting this issue will require reindexing your data."