You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ingest processor doesn't use schema to resolve fields into column names. It relies on table definition and field mangling. This is fine when Quesma manages the table definition, but it can lead to confusion when a human manages the table.
Here is an example:
Let's create a table
CREATE TABLE test (
`@timestamp` DateTime64(3) DEFAULT now64() COMMENT 'quesmaMetadataV1:fieldName=%40timestamp',
`attributes_values` Map(String, String),
`attributes_metadata` Map(String, String),
`foo` Nullable(String) COMMENT 'quesmaMetadataV1:fieldName=bar'
)
ENGINE = MergeTree
ORDER BY `@timestamp`
SETTINGS index_granularity = 8192 COMMENT 'created by Quesma'
Insert some data
insert into test(foo) values ('a')('b')('c')
Query Quesma
POST localhost:8080/test/_search
{}
It's fine for now. We've got 3 rows.
Let's ingest
POST localhost:8080/test/_doc
{
"bar": "xxx"
}
And query again:
POST localhost:8080/test/_search
{}
We've 'lost' some data
The table looks like
9. Schema
The text was updated successfully, but these errors were encountered:
Ingest processor doesn't use schema to resolve fields into column names. It relies on table definition and field mangling. This is fine when Quesma manages the table definition, but it can lead to confusion when a human manages the table.
Here is an example:
The text was updated successfully, but these errors were encountered: