SimpleXMLRPCServer recursive dictionaries

[jerch]

Und imho ist das nur redundant, wenn es in eine Dictionary umgewandelt wird, ansonsten speicher ich nur die Referenz um die 1:n Beziehung zuhaben, oder sehe ich das gänzlich falsch ?

Das zusätzliche Vorhalten der Referenz ist redundant. Das wird Dir schnell klar, wenn Du Dir überlegst, welche Daten Du korrigieren musst, falls ein Auto den Halter wechselt. Solche Konstrukte sind fehleranfällig, da Du zur Implementationszeit sicherstellen musst, dass die Daten konsistent bleiben.

wie weiß das Auto jetzt zu wem es gehört ? (intelligentes auto )

Gönne dem Auto einen Blick auf den Besitzstatus, in meinem obigen Bsp. auf die "globale" Halterliste, z.B. so:

Code: Alles auswählen

# Klasse Auto
...
    def who_owns_me(self, halter):
        for h in halter:
            for a in h.autos:
                if a == self:
                    return a
        return Halter() # default "None" Halter

Brauchst Du viele solche Zugriffe, kann es sinnvoll sein, ein dictionary zu erstellen:

Code: Alles auswählen

auto_zu_halter = dict((a, h) for h in halter for a in h.autos)

Hier hast Du allerdings wieder das Redundanzproblem und musst mit jeder Änderung das dictionary aktualisieren.

Und weil Du auf eine Rückreferenz bestehst :

Code: Alles auswählen

# auf empfängerseite
def set_backrefs(halter):
    for h in halter:
        for a in h.autos:
            a.halter = h

NB:
Ich weiss nicht, wie komplex Deine echten Objekte sind und ob Du nicht mit einer Übertragung der "reinen Daten" und Erstellen der Objekte auf Empfängerseite besser fährst. Auch würde hiermit der nötige Datenaustausch geringer. Sowas ginge z.B. mit einer klasseneigenen serialize()-Methode auf Senderseite und entsprechendem Konstruktor auf Empfängerseite, der aus den serialisierten Daten das Objekt restaurieren kann.
Das Übertragen von eigenen Objekten (also jenseits von standardisierten Datencontainern) macht eigentlich nur Sinn, wenn der Empfänger nicht deren Deklaration kennen kann (z.B. beim Einsatz von Fabrikmethoden u.ä.) oder die Serialisierung zuviel Aufwand bedeuten würde. Pyro wurde ja schon genannt.

[Xynon1]

Den oberen Teil, hättest du dir sparen können, dennoch danke für die Veranschaulichung und deine Mühen, so was weiß ich immer zu schätzen

Ja, stimmt, der Wechsel ist nicht vorgesehen, brauch ich auch nicht, aber das schildert deutlich das Problem.

Die auto_zu_halter Dictionary ist glaube ich noch weniger zuträglich, und wie schon gesagt ich habe weder eine globale Autoliste noch eine globale Halterliste.

Die Struckturen sind ziemlich groß, dies ist nur eine wo ich nicht mehr weiter wusste und da bot sich das an.
Und wie man sieht, nicht zu meinen Gunsten.

Ach ja, die Objekte müssen nicht restauriert werden, der Client braucht nur die Daten.

Also, ich denke ich werde einfach immer die einzelne Dictionary durch laufen, das erscheint mir im Moment am einfachsten und ging/geht ja auch schon. Auch zeitlich.
Nur wäre es jetzt noch schön wenn ich von der globalen "Halterliste" wegkomme.

[BlackJack]

@alle die hier die Redundanz ansprechen: Das mag ein Code-Smell sein, ist aber nicht zwangsläufig ein schlechter Entwurf. Man stelle sich zum Beispiel Daten vor, die letztendlich einen gerichteten Graphen beschreiben, bei dem auch Kreise, bis hin zu solchen mit zwei oder gar nur einem Knoten, vorkommen können. Selbst bei einer Baumstruktur können Rückverweise auf den Elternknoten oder sogar eine zusätzliche Verkettung aller Knoten je Ebene, super praktisch sein. Das mag mehr Aufwand bei der Modifikation bedeuten, aber die gibt es ja nicht immer oder die Vorteile der einfachen Navigation wiegen das wieder auf.

[ms4py]

Oder er macht halt doch das Ganze relational. Sqlite ist ja mit Python dabei und kann auch eine DB im RAM anlegen. Und dann existiert eine globale Halter- und Fahrzeugliste und man hat auch keine Performance-Probleme.

Die Daten musst du dann immer noch vernünftig an den Client übertragen, aber du hast dann keine Probleme mehr mit der Navigierbarkeit in beide Richtungen, du nimmst dann einfach nur die, die du brauchst)

[Xynon1]

Das ist definitiv auch eine Option, ich werde mir mal ansehen, wie komplex mein Server noch wird, eventuell lohnt es sich.
Momentan brauch ich das nämlich nur an einer Stelle.

[Xynon1]

Habe, mich jetzt dennoch mal mit pyro auseinander gesetzt.
Es ist von der Nutzung her wirklich genau das gleiche wie der SimpleXMLRPCServer, nur hat man mehr Möglichkeiten, bzw. ist die Documentation um Längen besser.

Werde das ganze darauf umbauen oder gibt es auch (größere) Nachteile bei pyro, welche ich Berücksichtigen müsste ?

[Leonidas]

Werde das ganze darauf umbauen oder gibt es auch (größere) Nachteile bei pyro, welche ich Berücksichtigen müsste ?

Pyro geht im wesentlichen nur als IPC zwischen Python-Prozessen. Wenn dir das reicht...

[Xynon1]

IPC ?

Entschuldige bitte meine "Unwissenheit"


Edit: Ich habe gerade noch gesehen, das es einen JSON-RPC Server gibt, hat damit hier jemand schon Erfahrung mit gemacht ?
bzw. kennt jemanden noch einen anderen der zu empfehlen wäre ?
Noch kann ich nämlich wechseln, da auf der Clientseite noch nicht viel gemacht wurde.

[Leonidas]

IPC ?

IPC.

[Xynon1]

- Das kürzel war mir unbekannt,
und nein, dann kann ich es nicht nutzen.

Momentan läuft es zwar auf dem selben Rechner, aber das wird sich später ändern.

Siehe nochmal mein Edit, vom vorherigen Post, falls dir dazu noch was einfällt...

Und Danke für den Hinweis.

[Leonidas]

Momentan läuft es zwar auf dem selben Rechner, aber das wird sich später ändern.

Darum geht es nicht. Ich wollte darauf hinaus dass es nur zwischen Python-Programmen geht, weil es ein eigenes Protokoll nutzt.

[Xynon1]

Ok, dann würde es gehen, als Client nutze ich auch nur Python.

Aber langsam bin ich verwirrt, es gibt soviele RPC-Server, aber nirgendwo finde ich einen Vergleich unter denen, wo die Vor- und Nachteile sind.
Ich bräuchte einen relativ schnellen und leicht bedienbaren. Könnte mir dort jemand eine Empfehlung geben, welcher sich dafür am besten eignet ?

[Leonidas]

Aber langsam bin ich verwirrt, es gibt soviele RPC-Server, aber nirgendwo finde ich einen Vergleich unter denen, wo die Vor- und Nachteile sind.

Simpel, kompatibel mit verschiedenen Sprachen: XML-RPC. XML-RPC in Enterprise(tm): SOAP. Simpleres Datenformat, weniger verbreitet: JSON-RPC, YAML-RPC. Schnell, vmtl. high performance: Thrift. Möglichkeit komplexe Datenstrukturen rumzuschicken: Pyro. RPC mit Corporate-Support: ZeroC Ice.

[Xynon1]

Danke