QSqlQueryModel::setQuery

[miki11]

Ich habe einen Textfeld, wo ein User sein Suchbegriff eingeben kann QLineEdit.

Desweiteren zeigt ein QTableView die Daten von QSqlQueryModel an.
z.Zt. lasse ich mit setQuery den Query ändern, wenn sich was im QLineEdit tut.

Das bremmst leider die Eingabe des Suchbegriffs teils für 1-2 Sekunden pro setQuery-Aufruf.

Wie wird sowas "schön" gemacht

[upsala]

Nach jeder Tasteneingabe 0.1-2s warten und dann erst die Query übergeben.

[miki11]

das hatte ich auch schon versucht, jedoch ist das auch keine schöne Lösung, weil auf der Benutzer kann bei der Eingabe schonmal Pausen einlegen und ich möchte die Anzeige auch aktuell halten währen der Anzeige.

Ich meine, selbst bei Web-Anwendungen, wie Google klappt das, daß während der Eingabe vervollständigt wird. OK dort ist nur eine einzeilige Eingabemaske.

Ich habe auch kein Problem damit, wenn es kompliziert wird, nur bin ich bis jetzt davon ausgegangen, daß da QT mir eh optimierte Lösungen anbietet, also wird ein eigenbau nicht schneller.

Irre ich mich dabei? Wo ist das Problem mit QSqlQueryModel::setQuery ? Was macht QT, daß das so hackt?
Es ist ja auch so, wenn ich nur 1-2 Felder anzeigen lasse.


Besser gesagt, zusammengefasst will ich eigentlich nur wissen, ob sich da lohnt selber Hand anzulegen. Hat da jemand schon Erfahrung gemacht?
Ich hatte auch schon daran gedacht in zwei Threads das ganze zu erledigen, habe aber noch keine Vorstellung davon, wie ich das machen soll.

[franzf]

Das Problem ist, dass ein setQuery() dein ganzes Model und die View resettet. Alles löschen und neu aufbauen. Das Problem gibt es bei der angesprochenen Google-Suche nicht, da muss nur ne Combo-Box gefüllt werden.

Ich denke sowieso, dass das der falsche Weg ist. Der User wird doch einen Such-String eingeben, und keinen eigenen komplexen Query. Somit reduziert sich doch alles auf einen initialen Query, mit dem du dein Model initialisierst. Den Rest erledigst du mit dem QSortFilterProxyModel.
Recht tief musst du da nicht einsteigen, schau dir einfach das Beispiel in "examples/itemviews/basicsortfiltermodel" an, das sollte ausreichend performant sein.

[upsala]

Vielleicht liegt es auch an einer langsamen Query...

[upsala]

QCompleter wäre auch noch eine Möglichkeit...

[miki11]

Hmm, dann hole ich mal etwas weiter aus.
Aber ersmal Danke schonmal für die Antworten.

Es geht um eine Tabelle, wo viele Daten stehen. Diese Tabelle wird mit andere Tabellen verknüpft um Kundennamen und Meldungfarben zu haben.
Ich lasse jedoch nur die 500 neuste Daten anzeigen.

An der Query liegt die Geschwindigkeit jedoch nicht, auch eine einfache SELECT mit wenigdaten macht das gleiche.

QCompleter geht daher nicht, weil diese ja dann nur in den vorhandenen 500 Datensätze durchsuchen würde, oder?

Alternativ könnte ich mich ja auch nicht auf die neusten 500 begrenzen, sondern alle abrufen, dann könnte ich ja QT eigene Filter nutzen, währe das schneller? Darüber habe ich noch garnicht nachgedacht, weil ich mir sagte, dafür habe ich SQL, soll der Server doch ackern und nicht die eventuell langsame Clients

Jedoch habe ich noch das Problem, daß ständig neue Daten reinkommen können. Kann ich diese neue Daten irgendwie in das vorhandene model einfügen?

Wobei, wenn ich jetzt mal Laut nachdenken darf...
Ich könnte ja ein Model selber schreiben, wo ich auch Daten einfügen könnte, oder vertue ich mich da und es ist möglich in ein QSqlQueryModel neue Records einzufügen?

[upsala]

Von welchen Zeiten sprechen wir jetzt eigentlich? Und vergiss nicht, daß du bei größeren Datenmengen auch die Übertragungszeiten miteinkalkulieren must. Genauso wie den Speicherbedarf.

[miki11]

wie ich schon oben schrieb, bei setQuery hatte ich die Wartezeit auch bei eine einfache SELECT Abfrage, wo nur zwei Zeilen mit eine Spalte sich ergeben hat.

Ich glaube, ich versuche da mein Glück mit einen eigenen an die Situation angepassten Model zu schreiben und das wohl auch im seperaten Thread. Dafür muss ich aber erstmal eine Thread-Sicheren Query machen.

[upsala]

Also sind deine Abfragen zu langsam. Lassen sich diese noch optimieren?

[phlox81]

Poste doch mal was code, bisher kann man hier nur rumraten, was genau noch wie verbessert werden könnte.

Und welche DB benutzt du?
Wie sieht die Query im Detail aus?

[miki11]

Also sind deine Abfragen zu langsam. Lassen sich diese noch optimieren?

hmm, ok deutsch ist nicht meine Muttersprachen, aber ich glaube mein obiger Text ist doch verständlich?! Ich habe doch schon zweimal gesrieben, daß auch bei einfache SELECT-Anfragen mit eine Spalte das Verhalten habe!

Also z.B. "SELECT data FROM xyz LIMIT 1"

Was ich jedoch herrausfand, bei QSqlRelationalTableModel habe ich bei weitem nicht diese Verzögerungen. Das kann ich aber überhaupt nicht nachvollziehen, weil QSqlRelationalTableModel von QSqlQueryModel abgeleitet ist und ein QSqlRelationalTableModel::select() ebenfalls setQuery aufruft. Also sollte genauso langsam/schnell sein.

Ich schreib erstmal ein kleines Testcode, wo keine störende Codestücke vorliegen und ich sichergehen kann, daß ich mich da nicht irgendwo ganz verhaue.

Erstmal danke, für alle Anregungen. Ich sag Bescheid, was ich rausfinden konnte.

[upsala]

Hab hier mal ein paar Zeitvergleiche gemacht. Ergebnis 15-30ms. Also ich finde das nicht lange.

[miki11]

Ich habe jetzt auch ein unabhängiges Programm geschrieben. Es klappt viel schneller. Irgendwo ist da tatsächlich noch etwas, wodurch sich mein Ablauf verlangsamt.

Ich habe mich wohl in irre leiten lassen, als ich das model getauscht habe von QSqlQueryModel.

Ich weiß nicht was da mein Problem ist, jedoch muss ich das Programm eh neu gestalten, damit alles übersichtlicher wird und Threads muss ich auch unbedingt einführen. Dann wird sich das Problem wohl eh erledigen.

Mal wieder sitzt das Problem von den TFT

Danke für euren Geduld.