Modo per consentire l'ispezione del modello di dati java dopo l'esportazione nel file

2

Ho refactored un programma per rimuovere la sua dipendenza da un database sql memorizzando tutto lo stato in un modello di memoria. Tuttavia, al gestore è piaciuta la possibilità di ispezionare facilmente lo stato del dominio semplicemente eseguendo un join / filtro SQL sul database in qualsiasi momento; e desidera mantenere alcune capacità di controllo del dominio simili. Abbiamo discusso di una chiamata che scarica lo stato del modello in un file che può essere ispezionato. Non c'è molto stato - tutto può essere contenuto nella memoria - ma lo stato è abbastanza grande che abbiamo bisogno di un meccanismo che ci permetta di "recuperare" il bambino se un dato genitore preferisce l'ispezione manuale dei file.

Ho bisogno dello strumento migliore per renderlo fattibile. Stanno pensando di esportare tutto in CSV per essere letto in un DB, il che potrebbe funzionare, ma sembra che stia usando un DB solo per fare join su tipi di dati. Inoltre, il loro vecchio approccio utilizzava stringhe per join che non erano garantite come uniche e, con la mia aggiunta di oggetti aggiuntivi, il pensiero avrebbe dovuto essere messo in modo da disporre i campi del database per rappresentare i nuovi oggetti del modello (in particolare oggetti figlio dei genitori).

Ho combinato con altre idee per questo. Un'idea riguardava un file CSV e alcuni programmi leggevano nel file CSV e facevano join "sql like", ma non hanno trovato un programma che lo faccia facilmente. Ho anche giocato con un interprete java interattivo in modo da poter leggere le cose nel nostro modello e fare chiamate contro il modello, anche usando i comandi di base di Linux per scrivere "join" con awk o simili. Non sono sicuro che mi piace qualsiasi opzione però. Qualcuno ha suggerimenti per un buon modo di farlo?

P.S. Siamo in grado di eseguire SSH sui sistemi mantenuti in qualsiasi momento, ma non possiamo copiare i file da o senza autorizzazione durante la manutenzione dei sistemi live. Qualsiasi strumento utilizzato per ispezionare la memoria deve essere impacchettato con il nostro rilascio come un proprio barattolo con la giustificazione del motivo per cui lo stiamo includendo.

    
posta dsollen 14.05.2013 - 21:19
fonte

1 risposta

2

Any tool used to inspect memory has to be packaged with our release as it's own jar

Abbiamo una restrizione per usare Java ... Questo rende alcune cose più facili e alcune cose più difficili.

Considera di avere qualcosa che serializza lo stato in xml e poi un programma separato per fare query xpath contro di esso. Questo ti dà alcune forme di query, ma non fa proprio i join (se non ne hai davvero bisogno, questo potrebbe essere l'approccio più semplice).

Non riuscendo a eseguire query xpath, si potrebbe invece serializzare i dati su qualcosa e portarli in un altro programma che utilizza un database incorporato. Qualcosa come HSQLDB o H2 oppure Derby o Sqlite . Allora hai due opzioni più ovvie ...

  1. Se il database è esposto, puoi utilizzare lo strumento sql preferito ed eseguirlo contro
  2. È possibile eseguire la query dalla riga di comando nell'applicazione stessa.

Un'altra opzione è semplicemente eseguire un dump della memoria dell'applicazione in esecuzione e utilizzare OQL per analizzare la memoria. Lo strumento per questo è il Analizzatore di memoria . Questo ci guadagna un po ', anche se ci sono molte più informazioni necessarie per affrontare questo problema.

    
risposta data 14.05.2013 - 21:36
fonte

Leggi altre domande sui tag