You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@metamodel.apache.org by "Arjan Seijkens (Jira)" <ji...@apache.org> on 2020/07/03 11:41:00 UTC

[jira] [Updated] (METAMODEL-1227) Better handling of nested objects in Elasticsearch data

     [ https://issues.apache.org/jira/browse/METAMODEL-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arjan Seijkens updated METAMODEL-1227:
--------------------------------------
    Description: 
If I index a document in Elasticsearch with nested objects, these are handled, as a fallback mechanism, as Strings by Elasticsearch, while they should be handled as Map, e.g.:

If I index this document:

{code:java}
{
	"user": {
		"fullname": "John Doe",
		"address": "Main street 1, Newville"
	},
	"message": "This is what I have to say."
}
{code}

The "user" field will be resolved to the "String" column type by the _ElasticSearchMetaDataParser_ class, which is default behavior when it doesn't find a "type" for a field. In this case we should resolve it to "Map", because that's what we actually get back when getting data from Elasticsearch which has been indexed like this. 

I added an integration test, _ElasticSearchRestNestedDataIT#testNestedData()_ on branch https://github.com/arjansh/metamodel/tree/bug/nested-data-in-elasticsearch to illustrate this issue.

  was:
If I index a document in Elasticsearch with nested objects, these are handled, as a fallback mechanism, as Strings by Elasticsearch, while they should be handled as Map, e.g.:

If I index this document:

{code:java}
{
	"user": {
		"fullname": "John Doe",
		"address", "Main street 1, Newville"
	},
	"message": "This is what I have to say."
}
{code}

The "user" field will be resolved to the "String" column type by the _ElasticSearchMetaDataParser_ class, which is default behavior when it doesn't find a "type" for a field. In this case we should resolve it to "Map", because that's what we actually get back when getting data from Elasticsearch which has been indexed like this. 

I added an integration test, _ElasticSearchRestNestedDataIT#testNestedData()_ on branch https://github.com/arjansh/metamodel/tree/bug/nested-data-in-elasticsearch to illustrate this issue.


> Better handling of nested objects in Elasticsearch data
> -------------------------------------------------------
>
>                 Key: METAMODEL-1227
>                 URL: https://issues.apache.org/jira/browse/METAMODEL-1227
>             Project: Apache MetaModel
>          Issue Type: Improvement
>    Affects Versions: 5.3.2
>            Reporter: Arjan Seijkens
>            Priority: Major
>
> If I index a document in Elasticsearch with nested objects, these are handled, as a fallback mechanism, as Strings by Elasticsearch, while they should be handled as Map, e.g.:
> If I index this document:
> {code:java}
> {
> 	"user": {
> 		"fullname": "John Doe",
> 		"address": "Main street 1, Newville"
> 	},
> 	"message": "This is what I have to say."
> }
> {code}
> The "user" field will be resolved to the "String" column type by the _ElasticSearchMetaDataParser_ class, which is default behavior when it doesn't find a "type" for a field. In this case we should resolve it to "Map", because that's what we actually get back when getting data from Elasticsearch which has been indexed like this. 
> I added an integration test, _ElasticSearchRestNestedDataIT#testNestedData()_ on branch https://github.com/arjansh/metamodel/tree/bug/nested-data-in-elasticsearch to illustrate this issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)