# Type of a Field

**URL:** <https://discuss.elastic.co/t/type-of-a-field/379238>\
**Category:** Kibana\
**Tags:** data-views\
**Created:** [June 17, 2025, 10:44am UTC](https://discuss.elastic.co/t/type-of-a-field/379238 "2025-06-17T10:44:45Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![madhavsankarg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/madhavsankarg/32/136239_2.png) [@madhavsankarg](https://discuss.elastic.co/u/madhavsankarg)\
**Post date:** [June 17, 2025, 10:44am UTC](https://discuss.elastic.co/t/type-of-a-field/379238/1 "2025-06-17T10:44:45Z")

</div>

Hi Everyone,

How can we make the type of a field(exception) permanently as object ?

I am facing issue where the type of the field sometimes gets assigned as text but required is object. According to the log which is first logged when roll over happens the field type will be decided as text or object.

---

<div class="post-metadata">

**Author:** ![Justin\_Castilla](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/justin_castilla/32/135379_2.png) [@Justin\_Castilla](https://discuss.elastic.co/u/Justin_Castilla)\
**Post date:** [June 17, 2025, 7:30pm UTC](https://discuss.elastic.co/t/type-of-a-field/379238/2 "2025-06-17T19:30:03Z")

</div>

Hello,  
Try explicitly defining the mapping of exception as an object. Also stopping dynamic mapping so it doesn't try to figure out what to use. Here's an example in an index template:

```auto
PUT _index_template/object-logs-test-template
{
  "index_patterns": ["object-logs-test*"],
  "template": {
    "mappings": {
      "dynamic": false,
      "properties": {
        "exception": {
          "type": "object",
          "enabled": true
        }
      }
    }
  }
}

```

Now create the index, add a doc, and observe the mapping:

```auto
PUT object-logs-test

POST object-logs-test/_doc?refresh=wait_for
{
  "timestamp": "2025-06-17T16:30:00Z",
  "message": "Test exception mapping",
  "exception": {
    "foo": "bar"
  }
}

GET object-logs-test/_mapping

```

The object should come through but not anything else, as dynamic is turned off:

```auto
{
  "object-logs-test": {
    "mappings": {
      "dynamic": "false",
      "properties": {
        "exception": {
          "type": "object"
        }
      }
    }
  }
}

```

---

<div class="post-metadata">

**Author:** ![madhavsankarg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/madhavsankarg/32/136239_2.png) [@madhavsankarg](https://discuss.elastic.co/u/madhavsankarg)\
**Post date:** [June 18, 2025, 9:47am UTC](https://discuss.elastic.co/t/type-of-a-field/379238/3 "2025-06-18T09:47:00Z")

</div>

Hi Justin,  
Its clear. I would like to know if any other data which comes other than in form of object for example number will that log totally be rejected ?

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [June 18, 2025, 10:22am UTC](https://discuss.elastic.co/t/type-of-a-field/379238/4 "2025-06-18T10:22:22Z")

</div>

Suggest to read:

> **[ignore\_malformed | Reference](https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/ignore-malformed)**
>
> Sometimes you don’t have much control over the data that you receive. One user may send a login field that is a date, and another sends a login field...

and

> [@Ignore\_malformed within an object](https://discuss.elastic.co/t/ignore-malformed-within-an-object/363147):
>
> Hi, can anyone provide confirmation or clarification if using ignore\_malformed on a property within an object is supported. The docs say they are not supported on object types but does this extend to properties within the object? for example : "dynamic\_templates": [ { "custom\_date\_iso": { "path\_match": "custom.\*", "match\_mapping\_type": "date", "mapping": { "format": "strict\_date\_optional\_time", "ignore\_malformed…

In your specific case, the type "object" is explicitly excluded from the use of ignore\_malformed, which would be a common approach in these cases.

I guess you _could_ try to use ingest pipelines to tidy up any bad input data ... often better to try to "fix" this sort of issue at source (excuse the pun).