2014-06-14 7 views
10

Mi trovo di fronte a un problema strano con Elasticsearch. La mia mappatura specifica che un certo campo è di tipo long. Ora accidentalmente stavo cercando di indicizzare alcuni documenti che avevano il tipo string per quel campo invece di long. Non ricevevo errori da Elasticsearch, ma i documenti non sono mai stati indicizzati. Quando ho risolto il problema, i documenti sono stati indicizzati correttamente.Elasticsearch fallisce in modo silenzioso se il documento ha una mancata corrispondenza di mappatura per un campo

Esempio:

mio mappatura:

{ 
    "field1": { 
     "type": "long" 
    } 
} 

Quando invio questo documento non riesce in silenzio:

{ 
    "field1": "this is a string" 
} 

Quando invio questo funziona come previsto:

{ 
    "field1": 12345 
} 

C'è un modo per rilevare questo tipo di errori?

+0

Puoi condividere la risposta che si stanno ottenendo indietro da elasticsearch quando si dispone di questo fallimento indice in silenzio? –

+0

probabilmente hai il flag [ignore_malformed] (https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html#mapping-settings) impostato su true a livello globale. potresti fornire un documento di esempio indicizzato che ha causato un errore silenzioso, anche la versione di elasticsearch. – keety

+0

Vedere la mia domanda aggiornata per un esempio. Penso che la bandiera che hai appena menzionato potrebbe essere ciò che stavo cercando. L'unico problema è che questo ignorerebbe il campo malformato ma indicizzerebbe comunque il resto del documento, il che non mi va bene dato che quel campo è richiesto. Mi piacerebbe che fallisse e restituire un errore se tenta di indicizzare un campo non valido. C'è un modo per farlo? –

risposta

4

Se si imposta ignore_malformed stringa su false. Non indicizza il documento se è malformato ma genera un'eccezione. Almeno in elasticsearch 1.6.0.

Esempio:

put test 

put test/test/_mapping 
{ 
    "properties" : { 
     "title" : {"type" : "string"}, 
     "data" : {"type": "long" ,"ignore_malformed":false} 

    } 
} 

put test/test/1 
{ 
    "data" : "1", 
    "title" : "valid coerce string to number" 
} 

put test/test/2 
{ 
    "data" : "hello", 
    "title" : "invalid number" 
} 

#Failed Response 
{ 
    "error": "MapperParsingException[failed to parse [data]]; nested: NumberFormatException[For input string: \"hello\"]; ", 
    "status": 400 
} 

Query with Get fails 

get test/test/2 


{ 
    "_index": "test", 
    "_type": "test", 
    "_id": "2", 
    "found": false 
} 
5

Ho il sospetto che la mappatura è simile a questo:

{ 
    "long_field": { 
     "type": "long" 
    } 
} 

Se questo è il caso, è possibile impostare il flag coerce per false come è true by default e sarà sempre cercare di convertire stringhe in numeri e troncare frazioni per interi.

{ 
    "long_field": { 
     "type": "long", 
     "coerce": false 
    } 
} 

Se si esegue questa operazione, la prossima volta che si tenta di indicizzare un campo lungo come una stringa, ES vi dirà questo:

MapperParsingException[failed to parse [long_field]]; nested: IllegalArgumentException[Long value passed as String]; 
+1

Q & A eccellente +1 +1 appreso da entrambi - grazie – Chris

+0

Grazie per la risposta. Sì, la mia mappatura specifica un tipo lungo (vedi la mia domanda aggiornata) ma vorrei indicizzare stringhe che non possono essere convertite in numeri interi. Quindi non penso che ciò funzionerebbe in questo caso, ma è utile per altri casi. Grazie! –

+0

Giusto per essere sicuri: "che non può" o "che può"? Il modo in cui capisco è che vuoi '" 123 "' (numero come stringa) e '123' (numero uguale a lungo) per avere successo, ma' 'non un numero" '(stringa errata) per fallire. È corretto? – Val

Problemi correlati