[Cologne-pm] Datenuebergabe von einem CGI-Scriptaufruf zum naechsten

Michael Lamertz mike at lamertz.net
Tue Jul 8 10:58:05 CDT 2003


n Tue, Jul 08, 2003 at 01:49:33PM +0200, Robert Meiser wrote:
> On Tue, 1 Jul 2003, Michael Lamertz wrote:
>
> > Wirf einen Blick auf die "Cache" Hierarchie auf search.cpan.org.  Dort
> > findest Du eine Vielzahl von Moeglichkeiten, die Daten zwischen den Hits
> > zu speichern.  "Storable" koennte, je nach Daten, auch interessant sein.
> 
> Hab ich gemacht. Scheint mir aber nur zu nützen wenn ich die gleichen
> Daten später nocheinmal _anzeigen_ will.

Eh?  Ich dachte, genau das willst Du?

    --------- snip ----------
    > > > Danach moechte ich gerne dem Benutzer die Moeglichkeit geben
    > > > die Datensaetze nach verschiedenen Feldern per Klick zu
    > > > sortieren. Dazu muss ich mir natuerlich zur weiteren
    > > > Verarbeitung die gefundenen Datensaetze ueber das Scriptende
    > > > hinaus "merken". 
    --------- snip ----------

> Zumindest ist mir nicht klar wie
> ich die gecachten Daten weiterverarbeiten, d.h. sortieren, kann bevor ich
> sie wieder anzeige.
> Storable scheint mir nicht viel anders zu sein als die 'Tie'-Lösung. Da
> würde ich dann lieber auf 'Tie' zurückgreifen, da die DB Module doch
> etwas weiter verbreitet scheinen in Standard Perl-Installationen.

Storable dumpt Dir Deine Daten - mit Ausnahme von Code-refs - so wie Du
sie im Speicher hast.  Einen fetten Hash-Ref-Tree kannst Du so mit einem
einzigen Befehl komplett auf Platte dumpen und spaeter genau so wieder
'reinziehen.  Die Sortierung die Du anzeigst musst Du natuerlich schon
durchfuehren, aber Du hast zumindest die vollstaendigen Daten bereits
komplett in der Hand ohne die DB nochmals zu clobbern - vorausgesetzt,
die Anfrage ist so komplex, dass sich das Caching auch lohnt.

Also:

Suche -> Result-Page, Session-Key, und Ergebnis in Cache.

Weitere Clicks wie Blaettern und Sortieren gehen dann via Session-Key
direkt in den Cache, wo Du die Daten beliebig verwursten kannst und sie
dann einfach wieder zurueck in den Cache schreibst, oder Dich einfach
immer wieder daraus bedienst ohne die Daten zu manipulieren.


Aber nochmal:

Das Einsatzgebiet fuer dieses Verfahren sollte schon genauestens
betrachtet werden.  Wie ja bereits an anderer Stelle diskutiert, sollte
nicht die evtl. gute Performance der DB durch einen maessigen Cache
mechanismus umgangen werden.  Und wenn die Result-Sets zu gross werden,
dann entsteht natuerlich auch nicht unerhebliche Last in Speicher und
Dateisystem.


Und nochwas:

> Storable scheint mir nicht viel anders zu sein als die 'Tie'-Lösung.

Nope, die sind schon ziemlich unterschiedlich.  Mit 'tie' bindest Du
eine xDBM an eine Variable, so dass diese sich verhaelt wie ein Hash,
aber in wirklichkeit eine Datenbank auf der Platte ist.  Saemtliche
Zugriffe auf Hash-Werte greifen hinter dem Abstraction-Layer direkt auf
diese DB zu.

Im Gegensatz dazu erzeugst Du mit Storable einen Snapshot eines echten
Hashes der im Speicher liegt, um ihn zu einem spaeteren Zeitpunkt wieder
vollstaendig in den Speicher zu ziehen.

Zwei komplett unterschiedliche Dinge - und ich meine mich zu erinnern,
dass das Stichwort 'tie' auch bei einem ganz anderen Teilproblem
gefallen ist.

> Robert ( der sich gerne eines besseren belehren lässt)

Done.  >:->

Komm zum Treffen, dann gibt's das ganze in mehr Details...

-- 
            Well, then let's give that Java-Wussie a beating... (me)

Michael Lamertz                        |     +49 2234 204947 / +49 171 6900 310
Sandstr. 122                           |                       mike at lamertz.net
50226 Frechen                          |                 http://www.lamertz.net
Germany                                |               http://www.perl-ronin.de 



More information about the Cologne-pm mailing list