Suggerimenti che progettano un demone di polling XML in python

1

Sto per intraprendere un nuovo progetto per un cliente che progetta un programma python sul lato server che eseguirà il polling di un certo numero di flussi XML a intervalli regolari e popolerà un database Postgresql con i risultati. Il sistema agirà fondamentalmente come un demone di cacheing XML e popolerà un database. Quel database sarà quindi accessibile da un programma separato che servirà quei dati in JSON a un sito web pubblico.

Mi chiedo se qualcuno abbia suggerimenti sul design di alto livello del programma di caching / polling di Python. Sto pensando a qualcosa di basato sulla classe in cui un certo numero di classi (una per ogni flusso XML da sottoporre a polling) discendono da una classe genitore comune, controlla la presenza di nuovi contenuti e poi ne acquisisce se trovati. Sto pensando di avere una tabella per ciascuno dei flussi XML sul database, una colonna per ciascuno dei campi XML e un'altra tabella per tenere traccia dell '"ultimo accesso" per ogni flusso.

Per questo ho intenzione di utilizzare Python 2.7, pyscopg e ElementTree per l'elaborazione XML.

Qualcuno ha qualche pensiero o critica sul mio design o toolchain a questo punto? Analizzare i miei valori XML per archiviare in un database Postgres più lavoro di quanto valga la pena? A proposito, il programma front-end che servirà quei dati lo trasformerà in JSON piuttosto che in XML.

    
posta b.b. 02.10.2013 - 22:03
fonte

2 risposte

2

Non sono sicuro del perché ti riferisci al demone come "caching"; probabilmente è meglio pensarlo come un demone di traduzione polling o di polling-adattamento. Sono spesso sorpreso da quanto sottili differenze tra i nomi possano cambiare il modo in cui pensi al problema.

Il tuo desiderio di ottenere i dati XML da XML è buono. Devo ancora vedere ogni caso in cui XML è utile per qualcosa di diverso dallo scambio dati ben definito e quindi solo quando XML è previsto da una parte o dall'altra. In altre parole, se voglio cercare il peso medio di una rondine a vuoto, scavare attraverso una pila di XML è il peggior modo in cui posso pensare di ottenere quei dati. Questo indica un altro punto in cui la tua scrittura è invertita rispetto al mio pensiero: lo schema dei dati è preminente, XML è solo un contenitore. Quando dici "colonna per ciascuno dei campi XML", penso "colonna per ogni campo dati". Sono abbastanza diversi da importare? Probabilmente.

Parli di classi ed eredità. Le persone cercano di usare l'ereditarietà molto più di quanto sia probabilmente utile (che è la sua diatriba), ma penso che potresti sovra-ingegnerizzare la parte di adattamento. Non vedo alcun motivo per preoccuparsi di costruire una rappresentazione in classe Python degli elementi di input quando il passaggio successivo è trasformarlo in un'istruzione SQL e inviarlo via. Da quel poco che hai dato, istanziare una classe per ogni riga potrebbe essere conveniente o potrebbe essere eccessivo; Presumo eccessivo, a meno che tu non possa dimostrare il contrario.

La scelta dello strumento è ovviamente corretta con un'eccezione: a meno che non ci sia un motivo che non hai fornito per preferire Python 2, usa Python 3. Il tuo futuro te lo ringrazierà tra cinque anni.

    
risposta data 03.10.2013 - 05:58
fonte
0

Penso che usare PostgreSQL abbia senso, forse più della maggior parte dei database. Uno dei grandi vantaggi di PostgreSQL è che hai un linguaggio di procedura memorizzato PL / Python [ link ] e ha anche un buon supporto JSON in / out [ link ].

Non voglio commentare la tua specifica implementazione, ma se hai dimestichezza con Python, puoi utilizzare stored procedure per archiviare i tuoi dati in modo efficiente e utilizzare il server di database per restituirli in JSON a qualsiasi client . Anche se, come detto, una volta che sono in JSON, probabilmente è meglio tenerli in questo modo [rispetto all'XML].

    
risposta data 23.01.2014 - 04:49
fonte

Leggi altre domande sui tag