suds-Objekte nicht picklebar, Alternativen?

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
EmaNymton
User
Beiträge: 174
Registriert: Sonntag 30. Mai 2010, 14:07

Mittwoch 8. August 2012, 09:13

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
deets

Mittwoch 8. August 2012, 09:25

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.
EmaNymton
User
Beiträge: 174
Registriert: Sonntag 30. Mai 2010, 14:07

Mittwoch 8. August 2012, 14:05

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!
Benutzeravatar
snafu
User
Beiträge: 5966
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Mittwoch 8. August 2012, 14:11

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.
Benutzeravatar
snafu
User
Beiträge: 5966
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Mittwoch 8. August 2012, 14:20

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?
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 ^^).
lunar

Mittwoch 8. August 2012, 18:50

@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.
EmaNymton
User
Beiträge: 174
Registriert: Sonntag 30. Mai 2010, 14:07

Donnerstag 9. August 2012, 09:11

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.
Antworten