[Allegro] Tertium non datur?

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Fischer, lieber Herr Eversberg,

> :nxt
>   (Hier ggfls. next #, wenn ALLE Daten verarb. werden sollen)
> next
> if no jump ende
> if del jump nxt
> jump loop
> 
> Und das klappt halt mit 'next #' nicht (immer).
> Spricht etwas dagegen, das 'if no' bei 'next #' (ist das derzeit überhaupt
> definiert?) mit derselben Bedeutung wie 'if cancel' zu versehen?

> Das würde die Analogie an dieser Stelle stärken.

Ich wuerde sie lieber abschwaechen wollen: Ergebnismenge zu Ende ist nicht
unbedingt Satznummer zu gross.

Da faellt mir ein, dass ich die im folgenden Skizzierte Mail einmal hatte
schreiben wollen: Bei den OAI-Schnittstellen geht es auch oft darum,
die ganze Datenbank zu exportieren, wobei optional gewisse Filterkriterien
angewandt werden und ausserdem die Anzahl der auf einen Schlag auszugebenden
Saetze oder Nummern gedeckelt ist (Export in chunks).

In frueheren Versionen habe ich mir die Startnummer gemerkt und dann eine
Schleife mit "next #" gebaut. Anlaesslich des Relaunchs neulich habe ich
das auf Ergebnismengen von Satznummern umgestellt, weil ich darauf naemlich
Restriktionen anwenden kann.

Beobachtung: find #1,2,3,4,5 etc.
zaehlt die in dieser Konstruktion mit eingesammelten geloeschten Saetze mit,
weil es aber eine Ergebnismenge ist, die mit "next" durchlaufen wird, bekommt
man sie dabei nicht zu gesicht, ist also nach weniger Iterationen als
angekuendigt "durch".

So ein Chunk darf durchaus einige tausend Elemente haben (der Client sollte
nicht mehr als einige MB zurueckgeschickt bekommen, wenn es nur um in XML
eingepackte Listen von Idenntummern geht, passt da viel rein), ich muss
solche find-Zeilen daher deckeln, damit selbst die neuerdings auf drastische
64kB erhoehte Zeilenlaenge fuer acon-Jobs nicht ueberschritten wird, bei
8stelligen Satznummern und einem Delimiter gehen also nicht mehr als ca. 7500
Nummern in eine find-Zeile. Abgesehen davon, dass man fuer ein Inkrement 5
Flexbefehle benoetigt, ist es auch extrem ineffizient, einen String 7000 mal um
ein bischen zu verlaengern: Da geht selbst Perl in die Knie.
Derzeit generiere ich die find-Befehle daher in der Anwendung vor, das heisst
aber, dass pro Chunk viele KB /an/ avanti uebertragen werden (und beim
typischen Harvesten kleiner Inkremente ist es dann wirklich so, dass die
Jobs deutlich umfangreicher sind als das Ergebnis, denn die x-tausend Nummern
sind ja nur der Startpunkt, Anwendung der Restriktion reduziert dies -
erfreulich performant - auf eine Handvoll wenn nicht gar keinen). Ausserdem
kann der Job in so einem Setting nicht endlos weiterrattern, er muss an das
Skript zurueckgeben, damit dieses einen Folge-Job mit neuen Satznummern
generieren kann.

Mein Desiderat daher: Es wird auch eine von-bis-Konstruktion fuer find #
benoetigt, also etwa

find #20001-30000

bildet eine Ergebnismenge aus den 10.000 Saetzen mit den internen Nummern
20001 bis 30000, unbesetzte dabei nicht enthalten, gloeschte wie gehabt mit
dabei.


viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAk2ckewACgkQYhMlmJ6W47OAIgP/RIKtd3fmC6vJ09p04ER9rdZc
qDoE1LeK2SvVpkuBTHttfJjgbN+Dq2+kK+5g5niktpYssuo+AEWb7ZSe0e6uijFk
ScaHflBPjRG/+Fb6nS0CnsAzKeAMhsioeftno6HPJD1Tecmdva6Z7tCeS+EfaM5O
eerrp+AOFDmXTQIvtzM=
=AebF
-----END PGP SIGNATURE-----