Django QuerySet: Anzahl verschiedener Einträge in ermitteln

[killercup]

Hallo liebe Forumgemeinde,

ich beschäftige mich seit einigen Wochen nebenbei mit Django und versuche aktuell eine kleines Statistik Funktion in mein Projekt einzubauen. Da ich nicht mehr weiter weiß und mir dieses Forum hier (wärmstens!) empfohlen wurde, hoffe ich, dass ihr mir einen kleinen Denkanstoß zur Lösung des Problems geben könnt.

Mein Stats-Model besteht aus 2 Tabellen, einmal die Hits und dazu noch eine Art Zusammenfassungs-Tabelle, in welche die Anzahl der Hits und der Besucher einmal am Tag überragen werden soll. Und da ist auch schon mein Problem. Die Anzahl der Hits zu ermitteln ist ja relativ einfach mittels count()-Funktion des QuerySets.

Bei der Besucheranzahl ist das aber leider doch einiges komplizierter. Ich möchte diese mittels der Anzahl der unterschiedlichen IP's (und später auch Sessions) bestimmen. Wie kann ich nun in meinem QuerySet nachzählen, wie viele unterschiedliche IPs eingetragen sind?

Ich bin da leider etwas aufgeschmissen, weil ich keinerlei Ahnung habe, wie ich das ermitteln kann, ohne mittels ziemlich aufwendiger for-Schleife einzeln durchzuzählen.

Ich hoffe, es gibt dazu eine Möglichkeit und ihr könnt sie mir sagen!

Viele Grüße und herzlichen Dank schon mal im Vorraus,

Pascal

[Leonidas]

Mangels besserer Idee würde ich einfach eine ``for``-Schleife nehmen. Spricht da irgendetwas dagegen? Die Performance mag wohl nicht optimal sein, aber hast du denn ein Performance-Problem?

[killercup]

Danke für die schnelle Antwort!

Die Performance mag wohl nicht optimal sein, aber hast du denn ein Performance-Problem?

Noch nicht Ich werd mal schauen, wenns wirklich keine andere Methode dafür gibt werd ich wohl oder übel das for nehmen. Performance ist ja auch nicht so schlimm, läuft ja schließlich nur einmal am Tag (oder maximal jedes mal wenn man die Statistik Seite aufruft).

[jens]

Ich möchte diese mittels der Anzahl der unterschiedlichen IP's (und später auch Sessions) bestimmen. Wie kann ich nun in meinem QuerySet nachzählen, wie viele unterschiedliche IPs eingetragen sind?

Die Lösung ist IMHO die SQL Funktion "group by" oder irgendwas ähnliches...

Hab spontan mal das gefunden: http://www.djangosnippets.org/snippets/236/
http://blog.awarelabs.com/?p=19

[killercup]

Danke für die Antwort, Jens!

Hmm, group by wär zwar genau das, was ich bräuchte, aber leider unterstützt Djangos DB API das nicht direkt, und der Umweg über direkten SQL Code finde ich etwas unbequem (ist einfach nicht so bequem/dynamisch wie die API selbst).

Ich habs jetzt mal, wie Leonidas vorgeschlagen hat, mit ner einfachen for-Schleife und ner Liste gemacht; das funktioniert einwandfrei, ist zwar nicht ganz so performant, aber es ist ja auch nur ein kleiner Cronjob,d er einmal am Tag ausgeführt wird.

[Hyperion]

Hmm, group by wär zwar genau das, was ich bräuchte, aber leider unterstützt Djangos DB API das nicht direkt, und der Umweg über direkten SQL Code finde ich etwas unbequem (ist einfach nicht so bequem/dynamisch wie die API selbst).

Ich kenne mich jetzt nicht so mit Django aus, aber ist denn direktes SQL so ein Riesenproblem? Ich meine, wenn die API das nicht unterstützt, dann greif doch lieber auf das Backend zurück, welches das unterstützt, anstatt das in Python nach zu implementieren. An SQL wird sich da so schnell nichts ändern, als das das undynamisch wäre

[killercup]

Ich werd mir das mal angucken, aber aktuell gefällt mir die Python-Lösung besser, weil ich es natürlich beliebig mit Variablen füttern kann und auch direkt meinen Tabellennamen und so nicht rausfinden brauch (der könnt sich z.b. ändern).

Habs jetzt so in etwa am Laufen, wenn ichs mal etwas größer ansetzen will, mach ich mir nochmal Gedanken drüber Und ich glaub ich sollte den Django Entwicklern mal sagen, das so etwas (group by) noch fehlt!

[sma]

Das hat man denen schon mehr als einmal gesagt Siehe z.B. Ticket #3566.

Das IMHO größte Problem bei Django ist, dass die Weiterentwicklung des ORM praktisch auf Eis liegt. Seit Monaten gibt es (neben dem newforms-admin branch, der auch nicht fertig wird) einen query-set-refactoring branch, in dem gefühlt nichts passiert, aber immer als Grund angeführt wird, dass in der jetzigen Codebasis nichts wesentliches mehr verbessert wird. Also heißt es seit Monaten warten auf Godot.

Ich will hier gar keine Lanze für z.B. sqlalchemy brechen, das fand ich viel zu kompliziert, aber statt dass eine Person, die sich möglicherweise überschätzt hat, was die zur Verfügung stehenden Zeit und die Aufgabe an sich angeht, das Projekt anhält, weil man alles neu machen will, wären inkrementelle Änderungen vielleicht doch besser gewesen.

PS: Rohes SQL ist nicht schwer, aber etwas umständlicher. Ich hatte schon über eine eigene kleine Abstraktion nachgedacht, um etwa wieder das Ergebnis zu Objekten zu machen.

Stefan

[killercup]

Das hat man denen schon mehr als einmal gesagt Siehe z.B. Ticket #3566.

Ja, das Ticket ist mir auch schon begegnet.

Das IMHO größte Problem bei Django ist, dass die Weiterentwicklung des ORM praktisch auf Eis liegt. Seit Monaten gibt es (neben dem newforms-admin branch, der auch nicht fertig wird) einen query-set-refactoring branch, in dem gefühlt nichts passiert, aber immer als Grund angeführt wird, dass in der jetzigen Codebasis nichts wesentliches mehr verbessert wird. Also heißt es seit Monaten warten auf Godot.

Das ist natürlich ziemlicher Mist, aber ich hoffe mal, da passiert noch was! Schließlich muss Django 1.0 ja auch bald mal kommen, wo das Django Buch doch gerade erschienen ist (grundlegende Änderungen wären jetzt ziemlich dumm, also sollten die Entwickler besser bist 2.0 damit warten…).

Gut, ein Vorteil an Django ist meiner Meinung nach, das es zwar ein ziemlich "hohes" Framework ist, man es aber gleichzeitig auch als "niedriges" Framework benutzen kann, indem man halt statt den vollautomatischen Funktionen die simpleren benutzt, auf denen die vollautomatischen auch aufbauen. Als Alternative dazu kann man dann natürlich auch ganz auf die Django Funktionen verzichten und z.B. reines SQL benutzen, also hat man durch Django dabei dann keine Nachteile (sondern eigentlich nur Vorteile durch die netten Funktionen). Das ist für mich eigentlich der Hauptgrund, warum ich Django überhaupt benutze.

(In meinem Fall wäre reines SQL zwar schön, aber weil ich die Daten eh abfrage und Performance bei einer Funktion die einmal am Tag läuft nicht so dermaßen wichtig ist, reicht mir die Python Implementation.)

[sma]

Das ist natürlich ziemlicher Mist, aber ich hoffe mal, da passiert noch was! Schließlich muss Django 1.0 ja auch bald mal kommen, wo das Django Buch doch gerade erschienen ist (grundlegende Änderungen wären jetzt ziemlich dumm, also sollten die Entwickler besser bist 2.0 damit warten…).

Ich bin da inzwischen sehr skeptisch. Meine Theorie ist, dass die Gruppe, die Django voranbringt, kein gutes Projektmanagement hat, wahrscheinlich auch nie gelernt hat. Die Einstellung "es ist fertig, wenn es fertig ist" und "mach's dir selbst, ich brauch's nicht" die aus manchen Antworten (in der Regel sind die aber super nett zu neuen Leuten) durchscheint werte ich als Indiz dafür. Das finde ich schade, denn eigentlich gefällt mir das System sehr gut und war der Grund für mich, in Python zu investieren.

Die beiden Sprints sind leider von außen gesehen eher verpufft. Im ersten Sprint haben sie eine Reihe von Kleinigkeiten erledigt, aber nichts weltbewegendes. Im zweiten Sprint haben sie sich selbst ins Knie geschossen, dass ungefähr die Hälfte der Zeit das System down for maintenance war und noch weniger geschafft. Okay, eine Reihe von Tickets mit dem Status "design decision needed" wurden zu in den neu geschaffenen Status "maybe later (maybe never)" überführt, doch größere Dinge - für die IMHO ein Sprint geschaffen wäre, weil man zusammen konzentriert an einem Thema arbeiten könnte - sind wieder nicht passiert.

Ich glaube, wir sehen Rails 2.1 (oder wird dann das schon 3.0 ;) früher, als eine Django-Version, egal welche Nummer sie da jetzt wählen werden. Diese unsägliche Diskussion - statt über Features zu diskutieren, ist man in das Für und Wider verschiedener Versionsnummern abgedriftet - war letztlich doch auch ergebnislos, oder?

Was ich sowieso nicht verstehen kann, ist die Weigerung der Kernentwickler regelmäßig Releases zu machen. Wenn das wirklich so viel Arbeit ist, wie gerne behauptet wird, dann muss man das automatisieren und daran arbeiten. Dennoch sollte es IMHO möglich sein, z.B. alle 3 Monate eine neue Version zu erstellen.

Auch eine Roadmap-Planung mittels Trac wäre echt hilfreich. Doch auch diese wird bewusst abgeleht. Klar, das sind alles Freiwillige und keiner wird für seine Arbeit bezahlt, aber wenn die ihre bezahlte Arbeit genauso machen, nun, das ist dann kein gutes Aushängeschild.

Muss ich mir doch wohl Rails 2.0 zusammen mit Ruby 1.9 (was ja Weihnachten erscheinen soll) mal zwischen den Tagen anschauen...

Stefan

[Leonidas]

Ich bin da inzwischen sehr skeptisch. Meine Theorie ist, dass die Gruppe, die Django voranbringt, kein gutes Projektmanagement hat, wahrscheinlich auch nie gelernt hat. Die Einstellung "es ist fertig, wenn es fertig ist" und "mach's dir selbst, ich brauch's nicht" die aus manchen Antworten (in der Regel sind die aber super nett zu neuen Leuten) durchscheint werte ich als Indiz dafür. Das finde ich schade, denn eigentlich gefällt mir das System sehr gut und war der Grund für mich, in Python zu investieren.

Wobei man zugeben muss, dass sie eigentlich nie Zeit hatten ein vernünftiges Management zu lernen. Du hast an dieser Stelle schon recht - wenn es vernünftige Releases gäbe, könnte man größere Sachen im SVN-trunk "kaputt" machen, um größere Features zu implementieren. Meist wenn etwas in einem Branch passiert ist sowieso absehbar, dass wenn er nicht von einem Kernentwickler betreut wird, dass der sowieso einschläft. Das war bei magic-removal so, das war bei unicode so. Django ist dummerweise schlicht zu groß für das aktuelle Team.
Die Sache mit den Releases ist eben, dass sie unglaublich auf Kompatibilität achten, bis es fast schon weh tut.

Muss ich mir doch wohl Rails 2.0 zusammen mit Ruby 1.9 (was ja Weihnachten erscheinen soll) mal zwischen den Tagen anschauen...

In Rails ist das noch schlimmer, DHH gibt sich nicht mal die Mühe nett zu sein Das ist O-Ton und wurde auf vielen Blogs diskutiert. Obwohl ich es jetzt nicht schlimm finde, zeigt dass, das Rails auf einer ähnlichen Schiene fährt wie Django.

Ich würde mir statt Rails lieber ein anderes Python-Framework ansehen. Leider gibt es außer Django nur eines, dass annähernd so gut dokumentiert ist.

[killercup]

Ich fänds ziemlich schade, wenn Django oder Rails in absehbarer Zeit so untergehen wie sie aufgegangen sind. Es steckt wirklich eine große Menge Potential hinter solchen Frameworks und ich persönlich habe etliche Monate Zeit gespart, um Python und Webentwicklung damit zu lernen, nur weil e mit Django so einfach geht.

Immerhin ist Django OpenSource, d.h. jeder kann es theoretisch um die Funktionen erweitern, die er benötigt und somit Django aufs nächste Level bringen. Die Basis des ganzen find ich persönlich schon ziemlich gut und stabil, für eine 1.0 auf jeden Fall geeignet.

Mehr als hoffen, dass in nächster Zeit was passiert, kann ich leider nicht.

[mitsuhiko]

Aber im Gegensatz zu Ruby können wir auf WSGI und SQLAlchemy zurückgreifen. Und so werden alle glücklich.

[sma]

IMHO haben sowohl WSGI als auch SQLAlchemy ein zu geringes Abstraktionsniveau. Außerdem möchte ich mir nicht mein individuelles Rahmenwerk zusammenpuzzlen müssen.

Ich sehe keine Gefahr, dass Rails untergehen wird - dort stecken bereits zu viele Investitionen drin. Bei Django könnte es eher passieren, denn genauso schnell, wie Leute zu einem neuen Rahmenwerk kommen, gehen sie auch wieder, weil sie zu einem anderen neuen Rahmenwerk kommen :) Zumal sich die Python-Gemeinde beim Web-Rahmenwerksbau gegenseitig Konkurrenz macht. Erst TurboGear, dann Pylons, dann ...

Django ist super, um schnell CMS-artige Probleme zu lösen, wo das Admin-UI seine Stärke ausspielen kann. Es ist jedoch nicht zu modular und von einer Wolke aus Plugins und Erweiterungen umgeben, wie es Rails ist und für das Deployment ist Capistrano AFAIK einzigartig. Hier ist bei Django Handarbeit angesagt, wo selbst Java-Application-Server-Deployment fortschrittlich wirkt.

Ich glaube nicht, dass das Team für Django zu klein ist. Im Gegenteil, erst ein kleines Team kann der Software die notwendige Einheitlichkeit und "Persönlichkeit" geben, das selbe, was DHH mit "Fuck You" gemeint hat: Habe eine klare Linie und sei davon überzeugt, dass sie richtig ist. Mit nett hat das übrigens weniger zu tun als mit seiner Art, Marketing zu betreiben. Rails bekannt gemacht hat er ja, indem er Java-Entwickler gereizt hat... finde das Zitat gerade nicht, aber irgendwas mit "poke with a stick in their eye and wait for a reaction".

Django ist nur zu groß, um am Wochenende und nach Feierabend entwickelt zu werden - und das scheint mir der aktuelle Weg zu sein, schaut man, wann die meisten SVN-Submits passieren. Hier fehlt das 37signals für Django.

Und leider ist Djangos klare Linie "wir machen keine Releases bis wir fertig sind" nicht kompatibel mit meiner Überzeug, wie es laufen sollte...

Das, kombiniert mit der größeren Aufmerksamkeit, dem besseren Deployment und der größeren Community (und JRuby + Glassfish = Enterprise-Kompatibilität) lässt mich etwas neidisch auf anderer Leute schöne Töchter blicken.

Stefan

[Leonidas]

IMHO haben sowohl WSGI als auch SQLAlchemy ein zu geringes Abstraktionsniveau. Außerdem möchte ich mir nicht mein individuelles Rahmenwerk zusammenpuzzlen müssen.

Was das Abstraktionsniveau angeht ist das kein Problem, denn für WSGI gibt es höhere Abstraktionen wie Paste, Pylons, Werkzeug. Das viele nicht dokumentiert sind ist natürlich noch ein anderes Problem. Für SQLAlchemy gibt es auch Elixir, was aber ebenfalls an Dokumentationsproblemen hängt. Wenn das mal vernünfig dokumentiert werden würde, wäre es nicht sonderlich viel komplizierter als Djangos ORM, dafür aber mit einem sich selbst pflegendem Untersatz.
Das zweite von dir angesprochene Problem besteht natürlich. Wobei TG 2.0 wohl plant so eine Art Pylons/Paste-Default-Set zu werden, d.h. eine Voreinstellung der Komponenten darzustellen die dann auch gut dokumentiert ist. Wir werden sehen was daraus wird.

Ich sehe keine Gefahr, dass Rails untergehen wird - dort stecken bereits zu viele Investitionen drin. Bei Django könnte es eher passieren, denn genauso schnell, wie Leute zu einem neuen Rahmenwerk kommen, gehen sie auch wieder, weil sie zu einem anderen neuen Rahmenwerk kommen

Mag zwar sein, aber die Anzahl der Django-Sites die existieren ist wesentlich größer als die aller anderen Python-Frameworks (womöglich sogar zusammen). Von daher wäre es ein riesiger Aufwand das alles zu migrieren.

Django ist nur zu groß, um am Wochenende und nach Feierabend entwickelt zu werden - und das scheint mir der aktuelle Weg zu sein, schaut man, wann die meisten SVN-Submits passieren. Hier fehlt das 37signals für Django.

Djangos 37signals heißt Ellington.