Inserimento di un documento JSON con `.` in chiave a MongoDB


14

Innanzitutto, si tratta più di una domanda di progettazione che di una domanda di programmazione.

Sto creando un'applicazione in cui devo recuperare i dati JSON esistenti e inserirli in MongoDB. Ho scoperto che alcuni dei documenti JSON hanno un punto .nella loro chiave. Ho letto nella documentazione MongoDB che i periodi .non sono consentiti come chiavi in ​​MongoDB poiché vengono utilizzati per le query.

Non faccio molti inserimenti nelle applicazioni web, è praticamente un inserimento una tantum. Inoltre, recupererei principalmente l'intero documento piuttosto che eseguire una query per parti di esso in quanto ho bisogno di ottenere tutti i dati.

Quindi, considerando i miei requisiti, ho due scelte su come archiviare il documento JSON:

  1. Cerca nel JSON il punto nelle chiavi e scappa e poi inseriscili in MongoDB.
  2. Converti l'intero JSON in formato BSON e memorizzalo come tale, evitando così la necessità di scappare, e analizza manualmente il JSON quando necessario all'esterno di MongoDB

Potresti dirmi quale sarebbe un design migliore, dato che non sono in grado di giungere a una conclusione.


Un modo per risolverlo è utilizzare il metodo insert e impostare il parametro check_keys su false. Un altro modo è quello di esaminare il documento e sostituire ogni occorrenza del punto dannato con qualcos'altro o un carattere unicode equivalente (beh, caratteri).
Noah,

Risposte:


3

Ci sono alcune alternative:

1. Sostituisci i punti con un trattino.

Questo sarebbe il mio approccio preferito, poiché mantiene la struttura abbastanza esplicita.

Dal momento che secondo te, "è praticamente un inserimento una volta", dovrebbe essere relativamente semplice controllare se non rompe nulla (cioè c'è già una stessa chiave con un trattino). Per altre situazioni, eseguire tali controlli a livello di codice richiede di scrivere del codice, ma è ancora un'attività relativamente semplice.

2. Sostituisci i punti con un carattere punto Unicode come U + FF0E .

Sconsiglio vivamente questo approccio, dal momento che porterebbe a enormi mal di testa durante il debug . Lasciare qualcuno che utilizza il JSON risultante da qualche parte nel codice lontano da MongoDB per indovinare che un punto non è in realtà un punto è un buon modo per perdere letteralmente settimane del tempo di qualcuno. Mantieni questi trucchi Unicode per gli hacker che vogliono indurre qualcuno a pensare che un personaggio sia diverso.

3. Usa BSON.

Dato che affermi che "recupererai principalmente l'intero documento anziché eseguire una query per parti di esso", questo approccio non presenta importanti inconvenienti nel tuo caso . Tuttavia, hai detto "principalmente", il che significa che a volte recupererai solo alcune parti del documento.

In generale, lo svantaggio è che non sarai in grado di cercare nel documento o di caricarne solo una parte.

4. Utilizzare una codifica standard, come Base64.

Convertire le chiavi problematiche (o tutte le chiavi, a seconda del rapporto tra quelle problematiche e non problematiche) in Base64 o esadecimale potrebbe essere una soluzione praticabile, con il vantaggio di essere piuttosto esplicito: la maggior parte degli sviluppatori riconoscerebbe i valori Base64 o esadecimali a colpo d'occhio .

Lo svantaggio è la maggiore impronta di memoria, nonché la necessità di codificare e decodificare le chiavi quando le si utilizza.

5. Impostare check_keyssu false.

Sconsiglio vivamente questo approccio, dal momento che renderebbe ambigua la query di dati e perdere ore o giorni a cercare di capire perché una query specifica non fa ciò che immaginavi debba fare. Dot è un personaggio riservato e il segno di spunta è qui per proteggerti; dicendo a MongoDB di saltare il controllo, rimanderai solo il momento in cui dovrai affrontare un conflitto tra la sintassi di MongoDB e il carattere riservato usato in una chiave.


0

Usa BSON. Quindi hai un formato ben documentato, con supporto di librerie ben collaudato e, soprattutto, puoi invertirlo (codificare / decodificare) senza perdita.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.