Konzertheld.de

Umwege verbessern die Ortskenntnis

Zufällige Artikel

Ausgewählte Infos

Dank des Perl-Skripts von MySQLDumper laufen Datenbank-Backups bei mir vollautomatisch. Mit der Funktion des regelmäßigen Aufräumens war ich aber nicht ganz zufrieden. Ich wollte gerne, dass immer die zehn neuesten Backups behalten werden und von den älteren nur noch eins pro Woche. Das geht mit folgendem Bash-Skript:

  1. #!/bin/bash
  2. # Get all konzertheld backup files reverse ordered (konzertheld_yyyy_mm_dd_hh_mm.sql.gz)
  3. FILES=`ls konzertheld_* -r`
  4. # Initiate
  5. i=0
  6. LWNR=0
  7. # Go
  8. for f in $FILES
  9. do
  10.   i=`expr $i + 1`
  11.   # skip first 10 backups
  12.   if [ $i -gt 10 ]
  13.   then
  14.     # Get the database name by extracting the substring before the position of the first _
  15.     # echo ${f:0:`expr index "$f" _`-1}
  16.     # Get the date part by extracting a 10 long substring from the position after the first _
  17.     DATUM=${f:`expr index "$f" _`:10}
  18.     DATUM=${DATUM//_/-}
  19.     # Get week number
  20.     WNR=`date +%V -d $DATUM`
  21.     # If we already had that week number this is an older backup from that week. Delete it!
  22.     if [ $LWNR -eq $WNR ]
  23.     then
  24.       echo $f
  25.     fi
  26.     # Set the last week number to the current one. So if the next backup is from a different week it will be kept, if not, deleted.
  27.     LWNR=$WNR
  28.   fi
  29. done

So werden von den älteren immer alle bis auf eines aus einer Woche gelöscht. Wenn man nur automatisiert backupt, kann man das natürlich auch ohne die Wochennummer machen und einfach jedes siebte Ei jede siebte Datei löschen, aber mit der obigen Methode werden auch alte Backups gelöscht, die man mal manuell angelegt hat. So wie ich an Tagen, an denen alle zehn Minuten die Datenbank explodieren könnte, so dass ich ständig Backups anstoße...

Wieder mal ein paar Updates am Blog.
Content

  • Die Themensuche ist in einer verbesserten Version fertig gestellt. Über der Titelzeile neben den Kategorien ist jetzt das Thema zu sehen (anklickbar), in der Vollansicht gibt es unter dem Post einen Link. Die Themensuche ist jetzt noch präziser und findet nun endgültig nur noch Artikel, die von mir als zu dem selben Thema gehörig gekennzeichnet wurden. Dafür musste ich das Trennzeichen nach | ändern, da Leerzeichen zu einer Oder-Suche führen und Unterstriche als Leerzeichen behandelt werden...
  • Das Titel-Tag [blog] ist rausgeflogen, ich habe nun eine eigene Kategorie für Posts, die den Blog betreffen eingeführt. Sie heißt Blog. Total kreativ, ich weiß.
  • Irgendwann letztens habe ich wohl mal den 200. Artikel veröffentlicht, es müsste der Vorab-Post zu den Kirchentagsberichten sein, aber aus irgendwelchen Gründen hat Wordpress zwischendurch mal die Zählung geändert und ich hatte 201 Artikel statt 200, obwohl ich gar keinen veröffentlicht habe. 8O
  • Ein paar Verbesserungen am Quellcode, um die Validität zu erhöhen. Wenn mir einer den Fehler nennt, der jetzt noch auftrittt... *kopfschüttel* Was unterscheidet diesen Link
    <a href="http://www.stepmania.com/" class="extern" target="_blank">Seite</a>
    von diesem
    <a class="extern" href="http://de.wikipedia.org/wiki/Tanzmatte" target="_blank">Wikipedia</a>
    außer der Ziel-URL? Richtig: Der zweite wird vom Validator als falsch angestrichen. :wall: (es ist nicht immer dieser, aber immer irgendeiner im Dokument - aber nur einer! Angeblich existiert bei diesem einen dann das Attribut target nicht.)

Backend & Datenbank

  • Es werden nicht mehr alle Überarbeitungen gespeichert, sondern nur die neusten zwei. Eigentlich brauche ich diese Funktion gar nicht, aber sie gibt irgendwie Sicherheit... Wie das geht, habe ich hier gefunden: Quelle
  • Die alten Artikelversionen habe ich dann direkt mal alle gelöscht, dadurch ist die Datenbank um 196 Artikel ärmer. Schöne Entlastung.

Schimpfen auf Wordpress

  • Das Wordpress-Tag "code" formatiert Code nur so, dass er wie Code aussieht, zeigt aber tatsächlichen Code nicht an. Sprich, Links bleiben Links und werden nicht als Quellcode dargestellt. Das da oben ist also ein Misch aus "code" und eigenem Gefrickel.
  • Wenn ich einen Artikel anfange und speichere am Tag x und dann später am Tag y fertig stelle und veröffentliche, ist das Veröffentlichungsdatum nicht Tag y, sondern Tag x. Sprich, irgendwann angefangene Artikel befinden sich nach dem Publizieren nicht oben. -.-

Für den Beitrag über Burger King-Gutscheine habe ich QuickPress* verwenden wollen. Allerdings sollte der Beitrag nach "Kurz notiert". Da das eigentlich eh die Kategorie ist, die ich verwenden würde, wenn ich Beiträge aus QuickPress direkt publiziere, bietet es sich ja an die als Standard zu verwenden.

  1. Wieso kann man eigentlich die Kategorie bei QuickPress nicht angeben?
  2. Wieso kann man die Standardkategorie nicht ändern?

Antwort auf 2.: Weil es einfach die Kategorie ist, die zuerst angelegt wurde. In der Wordpress-Datenbank werden Kategorien, Tags, Link-Kategorien usw. als "terms" gespeichert und in einer zweiten Tabelle wird deren Abhängigkeit ("term taxonomy") gespeichert. Eigentlich eine clevere Idee, nur leider werden so einfache Dinge wie Ändern der Standardkategorie dadurch erschwert.

Lösung: IDs der alten und der neuen Standardkategorie tauschen, danach die "taxonomy" von Hand anpassen (die neue Standardkategorie hat jetzt die Unterkategorien der alten). Funktioniert. hahahah

* QuickPress ist ein in Wordpress 2.7 neues Feature, mit dem man von der Admin-Startseite (Dashboard) direkt einen Artikel schreiben und veröffentlichen kann. Dabei kann man aber nur einen Titel und Tags angeben und als "Editor" bekommt man nur eine Textbox.

Seit ich bei E.ON den Programmcodeblock zum Update der Datenbank geschrieben habe, stört mich die irre lange Ausführungszeit. Es geht dabei darum, von ca 300.000 Datensätzen anhand zweier Felder zu prüfen, ob sie bereits in der Datenbank sind, und ggf. Ergänzungen vorzunehmen. Beide Felder enthalten numerische Werte.

Bisher habe ich dazu ein Recordset geladen, was alle Datensätze in der Tabelle enthält, und dann eine Schleife geschrieben die alle eventuell zu ergänzenden Datensätze durchläuft. Darin wurde dann jedesmal ein Filter auf das Recordset gesetzt, und entweder blieb dann genau ein Datensatz über oder keiner, wenn's keiner war, musste ich den ergänzen. Das hat natürlich immer ewig gedauert, so etwa 1,5h, denn je nachdem wie intelligent Access da arbeitet, waren das 300.000 Durchläufe - für jeden der 300.000 Datensätze.

Datenbankzugriffe beschleunigen in Visual Basic weiterlesen

 1

Icons by http://www.famfamfam.com/lab/icons/silk/

Photo copyright by me unless noted