guten Morgen

ich bastle schon eine kleine Weile an diesem Problem, aber irgendwie habe ich einen Knopf. Es handelt sich um eine Search-Routine mit Indexierung.

Die Angaben:

$undef,
$file
$user
$title
$subtitle
$location
$topbid
$text

sind alle vorhanden und im File korrekt mittels TAB getrennt. Ich kann alles problemlos auslesen.

Ich möchte jedoch drei Variablen, nämlich "$title,$subtitle,$text" mit dem allgemeinen Suchkriterium "keyword" auslesen, und brauche dazu eine Routine zum Zusammenfügen dieser drei Werte.

Wenn ich es so oder ähnlich mache, funzt nichts und ich erhalte die Meldung, dass dazu anstatt ein Array ein anderer "Wert" erforderlich sei ( Vergass den genauen Wortlaut).

next if index(lc ($title || $text), $search) < 0;


Kleiner Auszug :
---------

while( my $line = <INDEX>) {
my($undef,$file,$user,$title,$subtitle,$location,$topbid,$text) = split /\t/, $line, 8;

if($form{'searchtype'} eq 'keyword'){
next if index(lc $text, $search) < 0;

} elsif ($form{'searchtype'} eq 'username'){
next if index(lc $user, $search) < 0;

---------

Wäre für eine Hilfestellung sehr verbunden.

Gruss aus der Schweiz

Ernie

everyauction.info

Dein ganzer Code ist nicht gerade sehr robust.
Ein paar kleine Anpassungen...

Herzlichen Dank für Deine Hilfe.
Ich musste (aus welchen Gründen auch immer) nur noch

next if( index($text, $search) < 0 && index($title, $search) < 0 && index($subtitle, $search) < 0 );

in:

next if( index(lc $text, $search) < 0 && index(lc $title, $search) < 0 && index(lc $subtitle, $search) < 0 );

ändern, dann fuktionierte es bestens.

Ich werde wahrscheinlich noch mehrmals in diesem Forum anklopfen, bevor ich das "Ding", an dem ich arbeite, auf die "LGPL"-Allgemeinheit loslasse.

Ernie

dein Vorposter wollte die ganze Zeile klein machen, siehe Zeile 6.
Das geht so aber nicht. Ich vermute mal ein Flüchtigkeitsfehler.
Günstig ist es hier Zeile 6 und 7 zu kombinieren:

Dann brauchst du es später nicht. Damit hast du einige "lc" Aufrufe und möglich Fehler gespart.
Die Zeile 11 kann man auch kürzer schreiben:


Ach ja benutze bitte die "code"- oder "perl"-Tags Das verbessert die Lesbarkeit.

Herzlichen Dank, auch Deine Version funzt bestens, allerdings kann ich damit wahrscheinlch sogar etwas Rechnerzeit einsparen, da alles folgende bereits "lower case" ist . Ich werde einen Vergleichsversuch machen, wenn mein Ding mit 25'000 aktiven Testauktionen gleichen Inhalts zeigen muss was es kann. Wenn ich zwei drei 10tel Sekunden raushole, bin ich bestens bedient.

Noch eine kleine Frage. Ich hab so 'n langes Ding.

($title, $subtitle, $reserve, $inc, $desc, $image, $image0, $image2, $image3, $image4, $thumb, $thumb2, $thumb3, $thumb4, $itmcond, $shipto, $shipping, $shipby, $location, $payment, $pay0, $pay1, $pay2, $pay3, $pay4, $pay5, $pay6, $pay7, $pay8, $paynow, $paypal, $charges, $buyit, $count, $counter, $relist, $relistcnt, $feat, $catfeat, $bolditem, $pending, $hide, $snip, $dutch, $qty, $seller, $res1, $res2, $res3, $hist, @bids) = read_ ....whatever

Kommt in jedem Sub teils mehrmals vor. 50 Einträge lesen. Immer wieder neu.

Meine Frage dazu: Gibt es unter Perl eine Möglichkeit, diese Zeile quasi als $config{'itemcontent'} zu konfigurieren um dann nur noch mit $config{'itemcontent'} aufzufufen?

Oder macht sowas überhaupt (rechnerisch) einen Sinn?

Ernie

Wer meine Suchseite sehen will, hier ist der Link. Allerdings, erwartet ja nichts Fertiges, ich bin zuerst am "Einbauen" verschiedenster Dinge aus verschiedensten Scripts, die Optik kommt dann viel später, wenn alles drin ist und funzt.

http://www.everyauction.info/cgi-bin/dds/auction.pl?action=search1

Sorry, I habe vorhin gar nicht bemerkt, dass ich nicht eingeloggt war und als Gast antwortete. Zukünftig werde ich auch "Code" benutzen, wenn ich was eingebe.

Ernie

Zu deiner "Ich hab so 'n langes Ding" Frage: Da gibt es sicher Selbsthilfegruppen... ;)

Ernsthaft:
Sind das immer wieder die selben Daten? Oder holst du dir immer wieder neue?
Wenn es Immer die selben Daten sind, dann Speicher sie in einer Hashreferenz ( $hasref = { a=>'A', b=>'B' }; ) und übergebe sie den Funktionen. Wenn es dir auf jede Millisekunde ankommt kannst du einen Hash auch global definieren ( eine solche Liste von Einzelwerten global zu definieren ist sehr unübersichtlich )

Ich persönlich hätte bei so was eventuell eine Klasse definiert, die die Daten intern Normalisiert, und aktuell hält. Dann bräuchte man nur noch das Objekt ab zu fragen. Das Objekt selber könnte sich dann darum kümmern, die Daten zu holen, zu splitten, darin zu suchen etc.

Aber ich weiß zu wenig über den Hintergrund der Software, ihre Funktionen und Zweck, als dass ich dich gut Beraten könnte.
Allgemein kann ich sagen, dass eine gut durchdachte Datenbehandlung, die Software stabiler, schneller und leichter erweiterbar machen kann.

>>Sind das immer wieder die selben Daten? Oder holst du dir immer wieder neue?<<

@ topeg

Es geht um die Artikel-Datei eines Auktions Scripts. Zusätzlich zu den Angaben über den Artikel (50 Zeilen) werden auch die Gebote dazu (mit entsprechenden Bieter Information) eingetragen. (Flat DB System)

Die Linie definiert, in welcher Zeile der Artikel-Datei was gefunden werden kann. Und das sind für jeden Artikel andere Linien-Inhalte, nur die Linien-Zuweisungen, wie sie in der Linie als String-Variablen definiert sind, bleiben immer gleich, müssen jedoch in den einzelnen Sub's immer wieder neu gelistet werden, damit es funktioniert.

Die Idee war einfach, die Ansicht der Subs möglichst einfach zu gestalten und nicht mit überlangen Zeilen zu komplizieren. Ich habe sogar Text Editoren gehabt, die nicht einmal in der Lage waren, den ganzen Inhalt solcher Zeilen in die Zwischenablage zu kopieren und später an einem anderen Ort wieder vollständig einzufügen. Sowas wird dann natürlich zum Riesenproblem, wenn der Script nach einer Modifikation aus diesem Grund dann abstürzt...

Uebrigens, zu Flat-DB, ich weiss warum ich nicht auf "MySql-DB" umschalte. Es sprechen (für mich) zu viele Gründe dagegen. Nicht nur die Frage der Sicherheit. Auch die schiere Grösse einer solchen "einzigen" Datei wird irgendwann zum Problem. Da kann mir ruhig mal das eine oder andere FLAT Reg-File, aus was für Gründen immer, zur Sau gehen, deswegen läuft meine Auktion genau gleich. Die Datei wird einfach automatisch gelöscht. Und wenn man weiss, was die Leute so alles "probieren", sind mir viele kleine einzelne Dateien, die ich ggfls. auch mit meinem Text Editor reparieren kann, erheblich sympathischer als "mySql Admin" oder ähnlich unverständlicher Schrott.

Und wenn die Sachen gut verteilt und "indexiert" zusammengemischt werden, dann funzt es wahrscheinlich fast so schnell mit alles andere auch. Allemal für die vorgesehene "Script-Reichweite" von <> 10'000 Benutzern und <> 20'000 aktiven Einträgen. Für Leute, die mehr wollen, soll sowas dann ruhig auch etwas kosten dürfen...

Lange Rede, aber ich hatte gerade etwas Zeit

Ernie

Mit persönlich würde so ein Dateiformat nicht zusagen.
Ich hätte die Daten gruppiert in verschiedene Dateien und in einem Auktionsbezogenen Ordner zusammen gefasst. Z.B. Veränderliche Daten und Statische Daten extra gepackt (Beschreibungen, Bilder, etc.) ein "Masterfile" würde dann die vorhanden Ordner listen und eventuelle Zuordnungen machen.

Im Programm selber würde ich auf DBD::AnyData, DBD::RAM oder ähnliches zurückgreifen.

Weiterhin würde ich das Programm In zwei Teile teilen. Einen Serverprozess, der die Daten verwaltet, abgleicht und verifiziert, und einen CGI, das die Benutzerauthentifizierung und Darstellung macht und dafür auf den Server zugreift.
Denn was ein Programm langsam macht sind seine Interaktionen mit dem System. Vor allem Dateioperationen lassen sich nicht beliebig beschleunigen (durch schnellere Hardware z.B.)

Aber es bleibt ja alles dir überlassen. :-)

Das Dateiformat KANN ich nicht ändern, weil ich sonst die volle Kompatibilität zum EveryAuction Originalscript und den existierenden Add-Ons in frage stellen würde, und das will ich auf keinen Fall machen. Bitte um Verständnis.

Auktionsscript, Search-Funktion, Artikel- / Mitglieder-Verwaltung werden alles einzeln lauffähige Sektionen. Offene/geschlossene Artikel, Mitglieder, etc., werden in verschiedenen Dateien indexiert, Suchfunktionen laufen sowieso über Index-Files.

Der eigentliche Auktionsscript beschränkt sich daher hauptsächlich noch auf die Haupt- und Kategorie-Listings und einige allgemeineVerwaltungsarbeiten.
Die eigentlichen Reg-Dateien werden so nach Möglichkeit nur direkt aufgerufen, wenn der Inhalt dann auch in irgend einer Form bearbeitet wird.

"UA" hat in übrigens dieser Beziehung zum Beispiel "ganze" Arbeit geleistet, indem aus jedem kleinsten Sub eine lauffähige Individualdatei wurde, aber die rechnen auch mit anderen Zahlen. Mein Script soll eigentlich auch nur als erweitertes Fundament dienen, der (H)Ausbau liegt bei den Benutzern. Das Ganze soll ja zum "Spielen" anregen...

Ernie