MS SQL: Alle Tabellen leeren

Ich möchte das nicht jedes mal googlen:

In dem Zusammenhang: Flyway initOnMigrate in Play Applikationen:

CodeIgniter: Applikationsseitiges Datenbank-Caching

CodeIgniter hat eine “Database Caching”-Klasse, aber die habe ich auf die Schnelle nicht verstanden – und es musste schnell gehen 🙂

CodeIgniter hat auch einen generischen Cache, und der ist schnell verstanden. Zu beachten: Datenbank-Queries sind nicht cachebar, “nur” deren Result-Sets. Das sieht dann bsplw. so aus (hier als filebasierter Cache):

Danke, Marcel!

UPDATE:

Für schnelleres Austauschen des Caching-Mechanismus scheint sich das Folgende anzubieten – allerdings gibt es einen Bug: Wenn der Adapter (im Beispiel unten APC) nicht verfügbar ist, wird nicht der Fallback genommen m(

Deshalb: Entweder vorher checken, welche Treiber installiert sind – oder bei filebasiertem Caching bleiben, das scheint das zuverlässigste.

Unabhängig davon ist diese Methode der Treiberwahl natürlich insbesondere dann am flexibelsten, wenn ein Treiber nicht (mehr) verfügbar ist, und der erwähnte Bug zuschlägt.

UPDATE:

Es kann eine gute Idee sein, die Erstellung des Caches in einen eigenen Controller auszulagern. Auf die Art vermeidet man, dass die Anwendung für denjenigen hängt, der das Pech hatte, auf eine veraltete Cache-Datei zugreifen zu wollen.

Ich habe in der App die oben beschriebene Logik implementiert, allerdings mit einer TTL von 15 Min. Parallel rufe ich per Cron alle 10 Min den Controller auf (mit “-m 540”, also max 9 Min Laufzeit), der die Cache-Dateien erstellt – wobei ich in meinem Fall davon ausgehe, dass das Erstellen etwa 5 Minuten max dauert.

So findet die Anwendung immer aus Ihrer Sicht aktuelle (weil < 15 Min alt) Cache-Dateien vor, fällt aber gleichzeitig nicht um, wenn der Cron mal ausfällt.

WordPress: Posts sortieren über mehrere Custom Fields

In WordPress kann man eigene Daten zu jedem Post speichern, so genannte Custom Fields. Technisch funktioniert das so, dass pro Post und Field ein Eintrag in der Tabelle wp_postmeta angelegt wird.

Beispiel: Ein Rating-Plugin könnte pro bewertetem Post einen Eintrag <meta_key:rating> mit der Gesamtzahl an “Sternen” (1=schlecht, 5=super), und einen Eintrag <meta_key:raters> mit der Anzahl an abgegebenen Stimmen anlegen. Also zwei Zeilen in wp_postmeta pro Post, für den Stimmen abgegeben wurden. Genau so macht es “Post Rate“. Anmerkung: Man speichert das schon deshalb als zwei diskrete Werte, um bei der nächsten Bewertung wieder den Durchschnitt berechnen zu können – ich musste kurz überlegen, bis mir das klar wurde 🙂

So, nun hat man in dem Beispiel bewertete Posts, und möchte diese Posts vielleicht nach ihrer Bewertung sortiert anzeigen. Kann ja nicht so schwer sein, schließlich gibt es zB $wpdb mit get_results(). Zu einem Problem wird das (für jemanden, dessen SQL-Kenntnisse etwas eingerostet sind mich) dadurch, dass es eben zwei Einträge in wp_postmeta gibt – und beide speichern ihren Wert in wp_postmeta.meta_value! Für eine Sortierung müsste man die Bewertung (stehen unter <meta_key:rating> in meta_value) durch die Anzahl an Stimmen (stehen unter <meta_key:raters> in meta_value) teilen.

Lösung: JOIN. Erst habe ich einen LEFT JOIN versucht geklaut, aber der definiert sich so, dass er alle Posts ausgegeben hätte, selbst wenn für sie gar kein Rating abgegeben wurde. Deshalb also nur JOIN. Basierend auf dem Foreneintrag mit dem LEFT JOIN ist dabei folgendes entstanden:

Etwas wie AS lag mir schon auf der Zunge, allerdings eher als SELECT AS… das in einem (bzw. zwei) JOIN zu verwenden, und zwar sowohl in dem JOIN (“rating.post_id”), wie auch im ORDER BY hätte ich nicht hinbekommen. In diesem Sinne: HTH 🙂

PS: Die formatierte Ausgabe ergibt sich dann aus dem bereits erwähnten Eintrag.