Hallo Zusammen, wird wohl heute mein Emailtag...
2013/11/14 Thorben Thuermer <r...@constancy.org> > > andi hat halt seine optimierungen nur gegen mysql gemacht und getestet, > und den fall anderer dbms dabei kaputtgemacht. > das ist auch nicht weiter tragisch oder verwunderlich, > da eh 99% der user mysql einsetzen. > > zumal im Code der vor mir da war exlpizit dokumentiert ist dass nur MySQL unterstützt wird. Die GroupBy Anfragen funktionieren ebenfalls nur mit MySQL... > loesungen, in order of preference: > - code fixen so dass er ueberall funktioniert > - die optimierungen nur bei mysql aktivieren > (eh fraglich, ob die bei anderen dbms was bringen!) > - support fuer andere dbms verwerfen, da eh irrelevant > > > PS: Wie sieht es denn mit "Issues" bei Github aus? Ich fände es ganz > > praktisch, wenn man da Fehler melden könnte. Da hat man dann auch den > Bezug > > zu Bugfixes. > > JUSTIN!!! > +1 +1 +1 von mir. > - T. > > On Wed, 13 Nov 2013 22:33:13 +0100 > Robert Ewald <robert...@jtro.de> wrote: > > Hallo allerseits, > ... > > Ich versuche es jedenfalls gerade mit SQLite. Es werden zwar erfolgreich > > Daten erfasst und in der Datenbank gespeichert, aber die Weboberfläche > > meldet Fehler. Der Grund ist folgendes Statement: > > SET @row:=... > > > > Das ist MySQL-spezifisch und dürfte bei keiner anderen Datenbank > > funktionieren. Die Jungs von SQLite haben lokale Variablen als Anzeichen > > ineffizienter Abfragen verworfen und bei Postgresql heißt es schlichtweg > > anders. > > Und es ist auch ganz einfach zu lösen: die übergeordnete Schleife mit && false deaktivieren, dann wird die Aggregation wieder in PHP statt MySQL gemacht. Ist halt langsamer... vg Andreas
