Beiträge verschlagwortet als “Plattenverwaltung”

Was mich immer wieder an meiner Plattenverwaltung gestört hat ist, dass sie nicht portabel ist. D.h. um was an einem anderen Rechner auszuprobieren, müssen folgende Kriterien erfüllt sein:

• (von Runtimes und .NET-Frameworks rede ich mal nicht)
• SQL-Datenbank muss installiert sein
• Die Coverbilder müssen genau unter dem Pfad zu finden sein

Letzteres war diese Woche der Fall, dass mein Programm schlicht und ergreifend abstürzte. Ein kurzes Debugging zeigte, dass der Versuch, eine nicht vorhandene Bilddatei zu laden, zu einer Exception führte und dann beendete sich das Programm unschön.

Der Bugfix war schnell gemacht, aber das Problem war ja eigentlich, dass ich die Bilder nicht - oder nur schlecht - immer mitnehmen kann. Lösungsmöglichkeiten gibt es da ja viele. Entweder ich lebe damit, kein Bild zu sehen oder ich mache die Datenbank beweglich und schiebe die Bilder in die Datenbank. Die Datenbank mobil zu machen oder online zu haben, nennt man in diesen Zeiten "in der Cloud".

Ich habe mich also mal bei Microsoft umgesehen, die mit Azure jegliche Art von Cloudaktivität anbieten, unter anderem auch DaaS (Database as a Service). Nur das Bezahlkonzept blieb mir etwas verschleiert, weil einmal hieß es ca. 5 Euro im Monat für die kleinste Stufe, auf der anderen Seite gab es transaktionsbasiertes Bezahlen. Aber um dahin zu kommen, brauch ich erstmal den ersten Schritt: Das Cover in der Datenbank speichern.

Also fing ich an, das Datenmodell anzupassen. Danach suchte ich nach Wegen, wie ich das Bild im passenden Format geladen und gespeichert bekomme. Danach nur noch von der Oberfläche bis zum Datenbankzugriff die Daten durchreichen (ich musste von dem einfachen Pfad auf ein Objekt umstellen) und schon war eine neue Version fertig.

Ziemlich lange blieb ich noch an einem Bug hängen, warum das Bild bei Tonträgern, die aus mehreren Platten bestehen und wo jeder Tonträger sein eigenes Cover hat, nicht geändert wurde. Letztendlich fand ich den Schlingel und nun arbeite ich wieder stabil. Momentan arbeite ich noch mit den Backup, d.h. wenn ich das Bild nicht in der Datenbank finde, dann lade ich es vom hinterlegten Pfad, aber das werde ich über kurz oder lang auch entfernen, damit ich die entsprechenden Bilder in die Datenbank bekomme.

Mit meiner letzten Version habe ich es ermöglicht, dass ich die Charts nicht nur eines Jahres anzeigen kann. Dabei fiel mir auf, dass ich seit 2004 meine Charts bei Jahreswechsel auf die Platte gedumpt habe. Dort standen dann mit Komma getrennt, Interpret, Titel und die Anzahl, wie oft die Platte gespielt wurde, drin. Und da wurde mir klar, dass man beides gut miteinander kombinieren kann.

Also begann der lange, steinige Weg zur Version 4.4. Erstmal habe ich mein Projekt, dass bei BitBucket gehostet wird, auf den Git Flow umgestellt. Vorher war das eher Kraut und Rüben. Da ich ganz allein an dem Projekt arbeite ist, stellt mir meine Quellcode-Verwaltung das Branching Model als Linie dar, da nie Änderungen auf mehreren Zweigen erfolgen.

Ich begann ganz zaghaft mit einer Oberfläche, dann habe ich das Einlesen und Zerlegen der alten Charts-Dateien in Angriff genommen und diese dann über die Datenbankschnittstelle finden lassen. Dabei entstehen zwei Töpfchen: gefunden und nicht gefunden. "Nicht gefunden" kann heißen, dass ich die Bezeichnung geändert / verbessert habe oder die Platte verkauft wurde. Also gab es zwei Optionen: "Verwerfen" - das ging schnell und "Zuordnen" - das hat den Großteil der Zeit gekostet.

Für das Zuordnen musste ich erstmal jede Menge Komponenten, die ich schon für die "normale" Plattenverwaltung gebraucht habe und eine gemeinsam genutzte Komponente umziehen, Aufrufe korrigieren und dann konnte das Zuordnen beginnen. Nächste Hürde: Bisher hatte ich nie das permanente Wechseln zwischen zwei Screen (Übersicht und Suchmaske) in meinem Prozess. Die Datenbank rebellierte etwas, weil die Verbindung bereits geöffnet war oder der Garbage Collector sie mittendrin mal wegräumte.

Heute kam dann der letzte und entscheidende Schritt: Ich hatte alles soweit fertig, las die Datei ein, ordnete zu und lies mir nochmal die eingelesene Zeile und das zugeordnete Datenbankobjekt rausdumpen. Und irgendwie passte bei den manuell zugeordneten Sätzen zu Zuordnung nicht hin. Ursache war schnell gefunden: Die Charts basieren auf den einzelnen physischen Tonträger, die Suche für die Zuordnung aber auf den Veröffentlichungen. Klingt jetzt komisch, oder? Beispiel: Doppel-CD - die besteht aus zwei CDs, ist aber eine Veröffentlichung. Beides habe ich jetzt verwechselt. Jetzt musste ich nur schnell das komplette Programm mal kurz umbauen, damit sie Suche mit beiden Kriterien arbeiten kann und schon funktionierte alles.

Ich hatte jetzt die letzte Version der Plattenverwaltung mehrere Monate im produktiven Test und bin sehr zufrieden. Das Programm kann alles, was ich brauche, die Daten sehen aus, wie ich das erwarte. Im letzten Beitrag zur Plattenverwaltung hatte ich erwähnt, dass ich noch einige Punkte zum Thema Datenqualität und Statistik einbauen wollte, aber das habe ich lieber als Korrekturen direkt auf der Datenbank gemacht. Wenn ich so einen Blick auf die Daten werfe, sehe ich noch am ehesten, ob sich noch ein Fehler eingeschlichen hat.

Als das neue Jahr begann offenbarte sich eine kleine Unschärfe, an der eine Reihe von Änderungen hin. Als ich das erste Mal die Jahrescharts öffnete, sah ich nur, was ich dieses Jahr als abgespielt markiert habe. Die Vorgängerjahre, die ich im Datenmodell mit vorgesehen habe, konnten nicht angezeigt werden. Also bohrte ich ein Loch von der Oberfläche bis zur Datenbank durch, dass ich die speziellen Datensätze für die Jahrescharts auslesen kann. Und jetzt kann ich bei den Jahrescharts ein bestimmtes Jahr angeben und sehe sofort die passenden Daten.

Ich habe mir mit der nächsten Ausbaustufe doch ziemlich viel Zeit gelassen. Und dabei gab es nach außen hin relativ wenig zu tun. Zur Erinnerung: Ich wollte in meine Plattenverwaltung als nächstes das Bearbeiten bereits existierender Tonträger integrieren. Dazu musste ich einen Tonträger auswählen - habe ich schon für das Abspielen. Und dann brauchte ich die Maske, wo ich alle Daten zum Tonträger sehe - habe ich auch schon für das Anlegen. Wo sollte dann also das Problem sein?

Zum einen musste ich beide miteinander verknüpfen. Natürlich möglichst so, dass keiner den anderen kennt. Wie soll das gehen, wenn auch noch Daten ausgetauscht werden? Ich erfand eine Klasse, mit der ich Workflows abbilden kann. Die funktioniert nach dem einfachen Prinzip des Stacks, d.h. am Anfang werden alle nötigen Bearbeitungsschritte (in Form der Viewmodels) reingestopft und wenn ein Schritt fertig ist, dann schickt er eine Nachricht - je nachdem ob abgebrochen oder weitergearbeitet wird. Meine Workflow-Klasse hat sich für die Nachrichten registriert und dementsprechend wird die Bearbeitung des Stacks fortgesetzt oder abgebrochen. Den Nachrichtenmechanismus habe ich in dem Atemzug auch gleich mit eingebaut. Damit war es für mich sauberer Dateidialoge unabhängig vom Viewmodel zu öffnen. Das war jetzt auch nicht der unheimliche Aufwand.

Der ganze Aufwand wartete in der untersten Etage - da wo das Mapping zwischen den Datenobjekten und der Datenbank statt findet. Ich hatte bis jetzt eine Klasse die den ganzen Zugriff abgebildet hat. Mit über 600 Zeilen Code war die schon ziemlich unübersichtlich geworden. Also zerpflückte ich die Klasse nach den einzelnen Anforderungen: eine Klasse für das Abspielen, eine für die Charts, eine zum Anlegen von Tonträgern. Jetzt zerfiel das Ganze und es machte auch wieder mehr Spaß neue Funktionalität einzubauen. Da ich die gleichen Objekte zum Anlegen wie auch zum Editieren benutze, musste ich erstmal die Datenobjekte umbenennen und merzte in dem Zusammenhang auch noch eine Architekturschwäche aus: Alle Assemblys hatten eine Abhängigkeit in die Datenbankschicht, da dort die Datenobjekte definiert waren. Also lagerte ich diese gleich in ein neues Projekt aus. Kurz und gut - ich baute einmal das komplette Untergeschoss um.

Der neue Modus funktioniert fast gleich von Anfang an, weil ich viel vom Anlegen wiederverwenden konnte. Jetzt muss ich nur noch ein paar kleine kosmetische Korrekturen machen, dann kann ich mir Gedanken machen, was ich mir als nächstes vornehme. Am liebsten hätte ich eine Ansicht, die mir ein paar Statistiken u.a. zur Datenqualität liefert. Ich habe festgestellt, dass etliche Cover nicht übernommen wurden bzw. was sonst noch an Daten fehlt. Das wird dann wohl der nächste Schritt sein...

Meine Plattenverwaltung nimmt langsam Gestalt an. Nachdem ich die Basisfunktionen, die ich benötige (Anlegen, Abspielen und Alltime-Charts), fertig hatte, probierte ich ein bisschen herum und schaute, wie die Daten in der Datenbank landeten. Alles sah gut aus, deswegen konnte ich mich an die Version 4.1 wagen. Neue Features:

• Jahrescharts
• Anlegen soweit erweitern, dass man Veröffentlichungen mit mehreren Tonträgern (z.B. Doppel-CDs) erfassen kann

Die Jahrescharts waren wirklich simpel - ich musste die Alltime-Charts nehmen, andere Daten abfragen und fertig. Etwas kniffliger war da das Anlegen. Nicht die Datenstruktur - die ist ja simpel, schließlich hatte ich sie ja im Datenbankmodell schon so vorgesehen. Aber wie stelle ich sowas dar? In der alten Version wurde die Anzahl abgefragt und wehe, man hatte sich geirrt. Das sollte jetzt viel einfacher werden. Ich dachte schon an Tab-Reiter, verwarf den Gedanken aber wieder, weil auftauchende und verschwindende Tab-Reiter finde ich im Browser normal, aber sonst eher verwirrend. Ich entschloss mich einen Master-Detail-View zu nutzen, d.h. man hat eine Liste zu der man Elemente hinzufügen / entfernen kann und wenn man ein Element der Liste auswählt, erhält man die Detailinformationen, in dem Fall die Titel. Und wenn wir schon mal bei Detailinformationen sind - die musste ich auch aufspalten. Als Beispiel möchte ich z.B. die Blumfeld-Sammlung nennen - eine Box, die den Titel "Ein Lied mehr..." trägt, aber die ersten vier Alben der Band enthält (Ich-Maschine usw.). Jedes hat sein eigenes Cover und seinen eigenen Titel, aber alle teilen sie die gemeinsame Bezeichnung. Auch das hatte mein Datenbankmodell schon vorgesehen, jetzt musste nur noch eine Darstellung und die Umsetzung her. Ich habe eine kleine Schwäche für Expander, man kann da so schön unwichtige Informationen ausblenden. Also landeten die Liste mit den Tonträgern und die Detailinformationen (die zu 95% sowieso den Hauptinformationen entsprechen) in eingeklappten Expandern. Mir gefällt es so und es funktioniert auch richtig super. Beigefügt mal ein paar Bilder, sonst versteht man das Geschriebene doch eher schlecht.

[gallery ids="6086,6087,6088"]

Ich habe gerade mal geschaut... es war im Mai, wo ich den letzten Beitrag zum Thema Plattenverwaltung 4.0 geschrieben hatte. Es folgte eine lange Phase der Orientierungslosigkeit - wie sollte jetzt meine Oberfläche aussehen? Ich hatte vor Jahren auf Arbeit ein kleines Programm geschrieben, dass einige überschaubare Funktionen erfüllen sollte, die über Tab-Reiter auswählbar waren. So ähnlich stellte ich mir meine neue Oberfläche vor und fing an. Zuerst fing ich mit den Basics an: Die Tab-Reiter einzeln anwählbar machen und dementsprechend den Content auf der Hauptoberfläche (der nur simuliert war) umschalten. Dann spielte ich noch etwas mit Farben herum und gelangte dann zu einem ersten Entwurf, der mir zusagte.

Als ich anfing die einzelnen Aspekte der Oberfläche (Home, Anlegen, Abspielen) mit Leben zu füllen, kollidierte ich immer wieder mit meinen Farbeinstellungen. Also flog alles was farbig war, raus und schon arbeitete ich mit einer ziemlich nackt aussehenden Windowsoberfläche weiter. Als erstes ging es mit dem Abspielen los, da diese Funktionalität die einfachste war. Ich hatte schon mal mit einem Such-Control herum-experimentiert und band es ein. Bei meiner alten Plattenverwaltung hat es mich immer wahnsinnig genervt, dass ich ewig herumscrollen musste, um eine Platte zu finden. Es versprach alles einfacher zu werden. Die ersten Testläufe gegen meine simulierte Datenbank funktionierten perfekt. Also konnte ich mich dem nächsten Punkt zuwenden...

Das Anlegen war der nächste Punkt, den ich auf dem Plan hatte. Ich klebte erstmal alle Controls auf die Oberfläche, ordnete sie ein bisschen, sorgte für ein anständiges Databinding (Für Laien: Die Daten und die Oberfläche miteinander verknüpfen) und dann gingen die ersten Tests los. Hier klappte was mit der Aktualisierung nicht, da kollidierte der Datentyp mit der Darstellung. Kleine Problemchen, die ich alle mit einer Suchanfrage lösen konnte. Hin und wieder schon ich die Controls zurecht, bis ich so halbwegs zufrieden war. Es konnte der letzte und entscheidende Schritt folgen: Ersetzen der Dummy-Daten durch den richtigen Datenbankzugriff. Hier tat ich mich anfänglich schwer, aber als ich einmal den Rhythmus raus hatte, war auch die Datenbank zügig angebunden.

Nachdem ich begann die einzelnen Programmpunkte mal testhalber anzuwählen, wurden mir klar, dass mich das Design kolossal nervte. Das mit den Tab-Reitern war zu umständlich und verbrauchte ständig Platz. Lieber eine einfach Startoberfläche und dann von dort aus die einzelnen Programmpunkte anwählen. Gesagt, getan... Das Schicke daran war, dass ich mich nur um das Startmenü kümmern musste, alle anderen Programmteile schalteten schon von allein auf den vorherigen Punkt zurück.

Der Test konnte weiter gehen - einzelne Platten als abgespielt markieren. Die Datenbankanbindung arbeitete fast perfekt - einmal wurden alle Platten geladen und dann wurde entsprechend dem Filter immer nur ein- und ausgeblendet. Markierte Platten wurden in eine extra Liste geschoben, die zum Schluss gespeichert wurde. Nur der Filter brachte mich zur Verzweiflung. Einmal gefiltert, wurde die Liste nie neu sortiert, sondern die vorher ausgeblendeten Platten wurde einfach wieder unten an die Liste angehängt. Also - neu sortieren nach jedem Filtern. Hatte ich mich im Filter vertippt und die Liste war dadurch leer, konnte ich den Suchbegriff entfernen oder was anderes Suchen - die Liste blieb leer. Mh, ein Aktualisierungsproblem, auch gelöst. Jetzt endlich konnte ich den Punkt ordentlich ausprobieren. Dumm war nur, dass mir die Fehler erst auffielen, als ich die Daten schon in die Datenbank geschrieben hatte. Äußerte sich dadurch, dass auch nicht gespielte Platten in der Liste befanden. Nachdem vermeintlich alles erledigt war, markierte ich, verließ dem Programmpunkt, wählte ich in wieder an, markierte weiter und hoppla... da waren noch die alten Elemente in der Liste. Bloß gut, dass ich das rechtzeitig gemerkt habe.

Anlegen entpuppte sich größtenteils als Fleißarbeit. Natürlich mussten jede Menge Daten geschrieben und gelesen werden, aber das ging sehr zügig von der Hand. Meine größte Sorge war ob das Framework die Verknüpfungen zwischen den Objekten gut hingekommt. Aber auch das lief sauber durch. Einzig die Persistierung (das dauerhafte Speichen der Daten) stellte sich quer, denn ich habe eine Verknüpfung zwischen der Platte und dem Interpreten bzw. dem einzelnen Titel und dem Interpreten. Das bescherte mir bei einer Single mit 2 Titeln drei mal den gleichen Interpreten als neue Datensätze. Als ich damit fertig war, konnte ich in den Praxistest gehen. Seither läuft das Programm in der Betaphase, d.h. ich starte es in der Entwicklungsumgebung und schaue immer mal auf die Daten, die so hin- und herhuschen.

Viel Zeit habe ich nicht gebraucht, um das Programm zu schreiben. Es war ja nur eine einfache Konsolenanwendung, welche die Daten aus einer Textdatei gelesen hat, die Zeilen zerlegt hat und dann die automatisch erzeugten Objekte gefüllt hat, die abschließend in der SQL-Datenbank abgelegt wurden. Was mich wirklich Zeit gekostet hat, war die Datenqualität. Da ich bisher für meine Daten nur einfache Textfelder hatte, hatte ich stellenweise bis zu drei Bezeichnung für Label, z.B. "WARP", "Warp" oder "Warp Records". Das gilt natürlich auch für die Länder. Also habe ich immer wieder die Textdatei durchsucht, einheitliche Bezeichnungen gewählt und dann die Daten erneut eingelesen.

Wo es dann wirklich haarig wurde, war die Beschreibung, bei denen ich in letzter Zeit hinterlegt habe, wann und wo ich die Platten gekauft habe. Das hat insofern Spaß gemacht, weil da auch Texte wie "Zu Weihnachten geschenkt bekommen" drin standen. Also habe ich Weihnachten in den 24.12. umgewandelt, mich erinnert, wer mich das Geschenk gemacht hat... kurz und gut, ich habe versucht das Beste daraus zu machen. Mit der Belohnung, dass ich jetzt die Daten in meinem SQL-Server habe.

Jetzt wo ich die Daten im SQL-Server gespeichert habe, brauche ich sie erstmal eine ganze Weile nicht. Denn der nächste Schritt sind dann Grundfunktionen der Oberfläche. Primär will ich wieder fit werden, was WPF betrifft und deshalb möchte ich mich nicht mit Datenbankproblemen herumärgern. Ich kann mich noch an einen ersten Gehversuch vor ein paar Jahren erinnern, da wurden erstmal alle Daten aus der Datenbank in den Speicher geladen, auch wenn sie garnicht gebraucht wurden. Sowas will ich an dieser Stelle vermeiden. Aus diesem Grund werden meine ersten Testversuche mit einem Dummy arbeiten, d.h. alle Daten liegen im Speicher. Aber das ist schon der zweite Schritt. Zu Beginn möchte ich einfach eine Startoberfläche haben, damit ich mit Icons herumspielen kann und vielleicht auch eine glückliche Farbkombination finden.

Und schon ist sie da - die nächste Folge zur Plattenverwaltung V4.0. Ich habe eigentlich die letzten Jahre darauf "verschwendet", an meinem Datenmodell zu feilen. Werfen wir aber zuerst mal einen Blick auf das aktuelle Datenmodell, wie es in Version 3.x eingesetzt wird. Ich speichere die Daten in einer Textdatei. Dort steht pro physikalischem Tonträger eine Zeile drin, d.h. für ein Doppelalbum wären das zwei Zeilen. Dabei reihen sich folgende Daten durch Paragraphenzeichen getrennt auf:

• Interpret (bei Compilations steht hier "Verschiedene"
• Name der Platte
• Typ (Single, Maxi / EP, Maxi-CD, LP, CD, Compilation und CD-Compilation sind mögliche Werte)
• Nummer des Tonträgers (z.B. bei Doppelalben 1 von 2)
• Gesamtzahl der Tonträger
• Label
• Katalognummer
• Herstellerland
• Freitext (meistens enthalten: Ort und Datum wo ich das Ding gekauft hab)
• Pfad zum Coverbild
• Preis
• Währung
• Schalter, ob Titel vorhanden sind
• Wie oft wurde der Tonträger im aktuellen Jahr abgespielt?
• Wie oft wurde der Tonträger insgesamt abgespielt?
• Anzahl der Titel
• Jetzt folgen in Dreierpärchen: Interpret (nur bei Compilations gefüllt) / Titel / Länge des Titels

Daran war erstmal nicht viel fehlerhaft. Es gab nur einen tückischen Fehler: Wenn der Schalter, ob Titel vorhanden sind auf 0 stand, wurde der Tonträger nicht in den Charts berücksichtigt. Ansonsten habe ich versucht, so viele Ungereimtheiten zu entfernen, wie es nur irgend ging.

Schauen wir und das neue Datenmodell mal von unten nach oben an. Es beginnt mit dem Label, dass die Platten veröffentlicht. Früher war das mehr oder weniger Freitext, jetzt ist es normalisiert und ich habe die Chance zu sehen, welche Releases ich von welchem Label habe. Daran schließt sich der Release an. Unter Release verstehe ich die Zusammenfassung aller Tonträger die zu einer Veröffentlichung gehören, also z.B. das jetzt schon oft zitierte Doppelalbum. Ein Blick nach links zeigt und das Land, wo der Release herkommt. Folgt man in die Mitte des Bildes hängt dort Repräsentation der physischen Platte. Jede Platte kann ein Cover haben. Jetzt kommt eine Neuerung gegenüber dem alten Modell - ich habe gelernt, dass z.B. eine Maxi-CD eine Zusammenfassung von Typ und Medium war. In Zeiten des Downloads lade ich mir eine Maxi runter, die aber keine Schallplatte ist. Demzufolge musste eine Trennung her. Der Typ wäre jetzt "Maxi / EP" und das Medium "CD" oder "Vinyl" oder "Download". Für mich eigentlich eine der Verbesserungen in diesem Datenmodell.

Ganz rechts befinden sich die einzelnen Titel, die Interpreten zugeordnet sind, wie auch der Release einem Interpreten zugeordnet werden kann. Links oben habe ich jetzt Teile eingeführt, die ich zwar schon so gepflegt habe, aber nie richtig zugeordnet habe - den Kauf der Platte nach Ort, Wert und Währung. Es gibt dann auch noch das Jahr der Veröffentlichung separat - eine Verteilung der Platten nach Jahren lässt grüßen. Und zu guter letzt noch die Charts, die in Alltime-Charts und Jahres-Charts unterteilt sind. Neu ist hier das Datum des letzten Abspielen - so finde ich richtig alte Platten wieder. Was noch neu ist, ist der Name einer einzelnen Platte. Sammelboxen haben mich dazu gezwungen, z.B. wurde von Gas seine alten Werke unter dem Titel "Nah und fern" neu aufgelegt. Sie setzen sich zusammen aus den einzelnen Tonträgern "Königsforst", "Gas" usw.

Wie geht es jetzt weiter? Das Datenmodell ist da - jetzt müssen nur noch die Daten aus der Textdatei in den SQL-Server wandern, d.h. der nächste Schritt ist ein Datenkonvertierer, der die alte Datei nimmt, aufbereitet (gerade meine Einkäufe müssen von Freitext in sinnvolle Strukturen gebracht werden) und dann abspeichert. Dann kommt die unangenehme Aufgabe, dass ich die neu entstandenen Objekte bereinigen muss, d.h. "WARP", "Warp" und "Warp Records" müssen zusammengefasst werden. Wird wohl so laufen, dass ich die Korrekturen in der Textdatei vornehme und dann wieder von vorn einlese.