Repository navigation
[Maps] properly handle id collisions in Kibana index pattern - #48594
Conversation
|
Pinging @elastic/kibana-gis (Team:Geo) |
💚 Build Succeeded |
💚 Build Succeeded |
thomasneirynck
left a comment
There was a problem hiding this comment.
great catch.
I would not roll back that performance optimization, it remains relevant afaic.
| type: 'Feature', | ||
| geometry: tmpGeometriesAccumulator[j], | ||
| properties: properties | ||
| properties: { |
There was a problem hiding this comment.
This recreates the properties-object, copying everything. the reason the previous code specifically did not do this (https://github.com/elastic/kibana/pull/48594/files#diff-9c78f255b553d9556966390c977b5a08L80-L81) is because decoding should execute as tightly as possible. These are tight loops that benefit from being fast and have low mem-footprint. The main bottleneck is geometries (which can have deeply nested coordinate-arrays), but the same principle applies for properties. There's no harm in updating properties in place and copying the reference because the geojson collection is not reused elsewhere.
There was a problem hiding this comment.
As discussed offline, there is no way around this because otherwise we need a unique id per geometry in a document. I created issue #48829 to track how we handle array's of geometries.
The performance issues are much smaller then deep cloning the geometry since its just a single object where the geometry could contain multitudes of nested arrays
ES document source
FEATURE_ID_PROPERTY_NAMEimplemenation assumed_idwould be unique across an Kibana index pattern. This is not the case. This PR updates the logic to namespace_idwith_indexto ensure uniqueness and fix problems where two features share the same_idfor a layer.To test the problem run the following in console. Then create an index pattern
test*. Create a documents source fromtest*and verify both points are visible and you can page through tooltips for each