Hallo zusammen,
ich schreibe momentan einen Client, um die Fußballergebnisse von openlidadb abzufragen. Da das meine erste Begegnung mit SOAP ist, habe ich nach ein (zu) wenig Recherche suds verwendet, um die Abfrage zu erledigen. Soweit funktioniert das auch. Allerdings wollte ich, um unnötige DB-Abfragen zu vermeiden, die Daten der einzelnen Spieltage lokal speichern, so dass im Endeffekt immer nur dann neue Daten geladen werden, wenn es eine Änderung gab.
Das Problem ist aber, dass suds-objekte selbst direkt nicht picklebar sind (http://stackoverflow.com/questions/2167 ... ds-results), so dass ich jetzt vor einem kleinen Problem stehe. Mein Überlegung war es, einen Wrapper zu programmieren, der die Daten in eine dict schreibt, das ich dann picklen kann.
Alternative wäre noch eine anderes Modul als suds zu verwenden, jedoch habe ich da keinen Überblick. Ich wollte euch mal nach eurer Meinung fragen, wie ihr in dem Fall vorgehen würdet.
Gruß EmaNymton
suds-Objekte nicht picklebar, Alternativen?
-
deets
AFAIK ist suds trotz aller Schwaechen immer noch das Beste. Bleibt dir also nix anderes uebrig, als die Daten rauszuholen und in andere Objekte zu uberefuehren. Da wuerde ich aber eh zu raten, weil das pickling von Objekten mit beliebiger Klasse immer eher schlecht ist - du kommst in Probleme, wenn die Klassen sich aendern im source (oder via generator in deinem Fall), aber du gepickelte alte Instanzen laden willst.
Ok, danke für die Einschätzung. Habe mich dann mal ein wenig nach XML-Parsern umgesehen, sehe aber jetzt den Wald vor lauter ElementTrees nicht mehr, zumal XML für mich Neuland ist 
Was soll man da nehmen, lxml, xml? Oder gar keinen XML-Parser sondern die Daten direkt aus dem suds-Objekt abziehen, so wie ich es im Moment für die Anzeige mache?
Die Struktur des zu parsenden XML-Files kann man hier sehen:
http://www.openligadb.de/Webservices/Sp ... agueSaison
Über einen kurzen Hinweis wäre ich dankbar!
Was soll man da nehmen, lxml, xml? Oder gar keinen XML-Parser sondern die Daten direkt aus dem suds-Objekt abziehen, so wie ich es im Moment für die Anzeige mache?
Die Struktur des zu parsenden XML-Files kann man hier sehen:
http://www.openligadb.de/Webservices/Sp ... agueSaison
Über einen kurzen Hinweis wäre ich dankbar!
Viele hier schwören auf `lxml`. Wenn es stinknormales XML ist und du keine großartige Komfort-Funktionalität (z.B. XPath) benötigst, dann reichen aber eigentlich auch Python-Boardmittel aus - also ohne zusätzliches Modul.
Wäre auch meine bevorzugte Idee. Wenn eine Abstraktion mit bekannter Schnittstelle angeboten wird, dann kann man die auch ruhig verwenden. Oder hier besser gesagt: Lass diesen `suds`-Generator ruhig seine Arbeit machen (ich hätte vielleicht erstmal etwas eingehender lesen und *dann* antworten sollen ^^).EmaNymton hat geschrieben:Oder gar keinen XML-Parser sondern die Daten direkt aus dem suds-Objekt abziehen, so wie ich es im Moment für die Anzeige mache?
-
lunar
@EmaNymton: Überführe die per suds deserialisierten Objekte in eigene Objekte innerhalb Deiner Geschäftslogik. Solche Objekte kannst Du nicht nur beliebig pickeln, Du bist dann auch unabhängiger vom SOAP-Dienst. Ändert der Dienst seine Schnittstelle, dann musst Du nicht Deine gesamte Geschäftslogik, die mit diesen Objekten arbeitet, anpassen, sondern nur die eine Stelle, an der die SOAP-Objekte in Deine Geschäftslogik überführt werden.
Ganz allgemein würde ich dazu raten, jedwede externe Ressource, sei es Webdienst oder Datenbank oder whatever, innerhalb der Geschäftslogik in eine eigene Model-Klassen zu kapseln.
Ganz allgemein würde ich dazu raten, jedwede externe Ressource, sei es Webdienst oder Datenbank oder whatever, innerhalb der Geschäftslogik in eine eigene Model-Klassen zu kapseln.
Vielen Dank euch beiden für eure Ratschläge, habe es jetzt genauso gemacht und speichere für mich nur die wesentlichen Informationen in einer eigenen Klasse. Neben dem spürbaren Geschwindigkeitszuwachs verkleinert sich auch die Datengröße erheblich.