bytea: Cacheproblem(?)

Hallo zusammen,

ich speichere über folgenden Weg ein PDF Dokument als ‘bytea’ in einer Postgres-Datenbank (Python Script):

with open (mypdf,"rb") as f:
    filedata = f.read()
    filedata=filedata.encode("base64")
    
    
curs.execute("""UPDATE public.test SET document=%(bytea)s;""",{'bytea' : psycopg2.Binary(filedata)})
conn.commit()

An anderer Stelle wird das PDF dann auf gleichem Weg wieder aus der Datenbank geladen und kann vom Benutzer betrachtet werden. Alles wunderbar :slight_smile:

Ein Problem bekomme ich nur, wenn ich das PDF durch ein anderes ersetzen möchte. In diesem Fall wird nämlich immnoch das alte PDF angezeigt.

Kann es sein, dass Postgres hier auf irgendeine weise “cached”? Oder weiß sonst jemand, woran das liegen könnte?

Vielen Dank für jeden Hinweis!

Ähm, Du machst ein Update ohne WHERE-Condition?

Andreas

Nein, entschuldige - es ist natürlich ein WHERE dabei, hab es nur in dem Beispiel weggelassen. Was aber wohl nicht so klug war :slight_smile:

Ich denke nicht, dass Postgres “alte” Werte zurückliefert solange Du die Änderung sauber committest.

Ich würde folgendes prüfen:

  • Wird das Update wirklich korrekt committed?
  • Greift die Anwendung auf eine lokale Kopie zu die z.B. im Dateisystem zwischengespeichert wurde
  • Ich kenne Python nicht. Liegt da evtl. noch ein ORM dazwischen welches ein Caching macht?

Eine andere - davon unabhängige Frage: Wieso verwendest du ByteA, wenn du sowieso die Daten als Base64 kodierst?

Hallo zusammen,

entschuldigt, dass ich das Thema nach so langer Pause wieder aufgreifen muss, aber ich bin nicht früher dazu gekommen.

@ads:
Gäbe es denn eine bessere Möglichkeit? Ich kann nur leider das Datenfeld nicht mehr ändern, weil die DB schon seit Jahren produktiv im Einsatz ist und ich es mir dann wohl mit den bestehenden Datensätzen verscherzen würde.
Zu Deiner Frage, ob das Update richtig durchgeführt wird: Ich habe mal per diff den bytecode verglichen, der im bytea-Feld steht. Der ist immernoch der selbe (obwohl ich das Feld vor dem Update auch mal per “SET mypdf = null” geleert habe).

@castorp:
Was meinst Du denn mit einem “ORM”?
Nein, auf eine lokale Kopie sollte es nicht zugreifen. Wenn ich mir das neue PDF anschaue, dann ist das schon mit neuem Inhalt gefüllt.

Habt ihr noch eine Idee, was hier los sein könnte?

Vielen Dank!

ORM = Objektrelationales Modell, sowas wie z.B. SQLAlchemy in Python. Das würde zwischen psycopg2 und deinen Klassen sitzen und generiert die Datenbankanfragen und Transaktionen. Wird auch Persistenzlayer genannt. Recht empfehlenswert und gut, wenn es das Projekt erlaubt.

Ansonsten könnte ich mir das morgen mal anschauen, im Moment muß ich grillen :slight_smile:

Gruß Uwe

Gruß Uwe

Hallo Uwe,

na vom Grillen möchte ich dich natürlich nicht abhalten - wer weiß wie oft das noch geht diesen Sommer :slight_smile:

Danke für die Erklärung. Aber ein ORM benutze ich - soweit ich weiß - nicht. Ich wär Dir also sehr verbunden wenn Du bei einem Nicht-Grillwetter einen nochmal einen Blick darauf werfen könntest :slight_smile:

Viele Grüße, Hannes

Hallo zusammen,

so, Problem endlich gelöst :slight_smile: Es hatte letztlich aber nichts mit Postgres zu tun, sondern mit einer Software, die das gespeicherte PDF (bytea) dann aus der Datenbank aufgerufen hat. Sie hat schoneinmal geöffnete PDFs in einem temporären Verzeichnis gespeichert und auch nach einer Änderung trotzdem das alte PDF geladen. Ich hätte das früher merken müssen, wenn ich einfach die Bitfolge im bytea-Feld der DB geprüft hätte. Also: Sorry an euch - war viel Lärm um Nichts :slight_smile:

Trotzdem vielen Dank an alle, die versucht haben, mir bei diesem Problem zu helfen!

Viele Grüße, Hannes

Dann würde ich sagen, das wir uns als Entschädigung nächste Woche in Oberhausen sehen :wink: