# Noob question about object-string handling

**URL:** <https://discuss.elastic.co/t/noob-question-about-object-string-handling/9635>\
**Category:** Elasticsearch\
**Created:** [November 8, 2012, 6:54pm UTC](https://discuss.elastic.co/t/noob-question-about-object-string-handling/9635 "2012-11-08T18:54:15Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Daniel\_Myung](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/daniel_myung/32/2042_2.png) [@Daniel\_Myung](https://discuss.elastic.co/u/Daniel_Myung)\
**Post date:** [November 8, 2012, 6:54pm UTC](https://discuss.elastic.co/t/noob-question-about-object-string-handling/9635/1 "2012-11-08T18:54:15Z")

</div>

Hi,

We're in the midst of adding more ES to our infrastructure, but we've  
frequently run into object-string issues with the data we have in our  
system.

I understand that when data comes in the first instance sets the index  
precedence for how things are indexed:

A:  
{  
"something": {"is": "objectified"}  
}

vs.

B:  
{  
"something": "is a string"  
}

If I index B-\>A, both will stick with a mapping of string, whereas, A-\>B, B  
will fail.

Our historical data we want to index is riddled with json docs that fit  
more the A-\>B transition due to the way our input form data gets versioned  
over time. We do have ways of partitioning these versions to mitigate this,  
but we were wondering if there was an inbuilt way for ES to be tolerant of  
the A-\>B scenario.

Are there tricks or workarounds to find a way to say, multi\_field or  
dynamic template to allow for some tolerance of our admittedly ugly, er,  
schemaless data?

Thanks,

Dan

--

---

<div class="post-metadata">

**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\
**Post date:** [November 9, 2012, 8:31pm UTC](https://discuss.elastic.co/t/noob-question-about-object-string-handling/9635/2 "2012-11-09T20:31:20Z")

</div>

I would suggest renaming the field "something" into "something\_o" if you  
detect that it contains an object and "something\_s" if you detect that it  
contains a string before sending the document to elasticsearch. It will  
make your life easier in the future when you will start running queries  
against this field.

On Thursday, November 8, 2012 1:54:18 PM UTC-5, dmyung wrote:

> Hi,
> 
> We're in the midst of adding more ES to our infrastructure, but we've  
> frequently run into object-string issues with the data we have in our  
> system.
> 
> I understand that when data comes in the first instance sets the index  
> precedence for how things are indexed:
> 
> A:  
> {  
> "something": {"is": "objectified"}  
> }
> 
> vs.
> 
> B:  
> {  
> "something": "is a string"  
> }
> 
> If I index B-\>A, both will stick with a mapping of string, whereas, A-\>B,  
> B will fail.
> 
> Our historical data we want to index is riddled with json docs that fit  
> more the A-\>B transition due to the way our input form data gets versioned  
> over time. We do have ways of partitioning these versions to mitigate this,  
> but we were wondering if there was an inbuilt way for ES to be tolerant of  
> the A-\>B scenario.
> 
> Are there tricks or workarounds to find a way to say, multi\_field or  
> dynamic template to allow for some tolerance of our admittedly ugly, er,  
> schemaless data?
> 
> Thanks,
> 
> Dan

--

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 3:05am UTC](https://discuss.elastic.co/t/noob-question-about-object-string-handling/9635/3 "2017-07-06T03:05:05Z")

</div>

Closed on July 6, 2017, 3:05am UTC