Open selmaohneh opened 2 days ago
Für den DdfGuide werden die Daten plump in einer json-Datei auf Github gepflegt. Das ist quasi das Backend. :D Im jugendlichen Wahnsinn wurde sich dafür entschieden, weil die App komplett kostenlos laufen sollte.
So lief das hier auch noch bis vor ein paar Monaten, bevor ich auf SQL migriert habe :D Habe dann doch eingesehen, dass das keinen Sinn hat ohne Relationen. Jetzt leite ich das JSON nur noch aus der Datenbank ab.
Du hast IDs in der SQL-DB. Diese müssten dann noch mit in das json gepackt werden.
Sehe ich auch so.
Hatte das eigentlich eh bei der Migration schon vor, keine Ahnung, wieso ich das dann doch gelassen habe.
Dann hätte ich den Aufwand, meine bestehenden IDs auf deine IDs zu mappen. Alternativ könnten natürlich auch die IDs in der SQL-DB angepasst werden und dort meine IDs eingetragen werden.
Meine IDs will ich eigentlich nicht ändern, dafür müsste ich meine Datenbank zu sehr umbauen. Und der ganze Code basiert auch stark auf den rein numerischen IDs.
Ich fürchte, da musst du in den sauren Apfel beißen ;) Ich kann dir gern beim Mapping helfen. Über die Europa-Nr. sollte sich ja schon das gröbste automatisch lösen lassen.
Hierfür benötige ich die Amazon-ID der Folge. Sind das Metadaten, die du mit aufnehmen würdest?
Gerne! Das stand eh schon auf dem TODO: #28
Vielen Dank, ich schau mir das an.
Eher eine Anmerkung um ein paar Daten zu sparen: Es reicht die jeweilige ID für Amazon, iTunes, Spotify, etc. zu speichern. Der eigentlichen Link kann dann anhand der ID erstellt werden.
Ich weiß, ich hab' das ursprünglich u.a. so gemacht, weil sich das schöner in mein voriges Schema eingereiht hat. Aber das stört mich auch immer mehr, v.a. weil jetzt noch mehr IDs dazukommen/gekommen sind. Hatte eh vor, das zu ändern.
Aktuell mache ich ja genau das Gegenteil, wenn ich die /index/*
-Weiterleitungen generiere: nämlich die IDs aus den URLs ziehen. Bisschen bescheuert.
Wahrscheinlich werd ich das im gleichen Zuge mit umstellen und, wie du meinst, nur die IDs speichern.
[Drei Fragezeichen Kids] sind ja aber, laut deiner Email, schon in Arbeit :-)
Genau, sind fast fertig! Ist in #25 getrackt.
Sind gute Punkte und sollte nicht zu viel Arbeit sein :) Ich setz mich gleich nach den Kids-Daten dran!
Nochmal Moin!
Meine App, der DdfGuide, ist schon vor 7 Jahren entsanden. Da haben wir uns leiden zeitlich knapp verpasst.
Nun pflege ich aber aktuell genau die gleichen Daten wie du, und das ist natürlich Quatsch. Ich denke daher darüber nach zu dreimetadaten zu migrieren.
Für den DdfGuide werden die Daten plump in einer json-Datei auf Github gepflegt. Das ist quasi das Backend. :D Im jugendlichen Wahnsinn wurde sich dafür entschieden, weil die App komplett kostenlos laufen sollte.
Hier meine Gedanken/Probleme:
IDs
Ich benötige zu jeder Folge eine eindeutige
guid
. Nutzer können sich Folgen favorisieren und/oder als gehört markieren. Dies muss über dieseguids
passieren, damit die Information bei einem Update, z.B. des Folgennamens, nicht verloren geht. Du hast IDs in der SQL-DB. Diese müssten dann noch mit in das json gepackt werden.Dann hätte ich den Aufwand, meine bestehenden IDs auf deine IDs zu mappen. Alternativ könnten natürlich auch die IDs in der SQL-DB angepasst werden und dort meine IDs eingetragen werden. Das verschiebt die Arbeit weg von mir direkt zu dir :D
Amazon
Ich biete in der App einen Link zu Amazon an. Nicht zu Amazon-Music, sondern zum Amazon-Shop. Das ist ein Affiliate-Link zu der CD der Folge. Hierfür benötige ich die Amazon-ID der Folge. Sind das Metadaten, die du mit aufnehmen würdest? Diese sind ebenfalls hier zu finden: https://github.com/selmaohneh/DdfGuide/blob/master/dtos.json
Links vs. IDs
Eher eine Anmerkung um ein paar Daten zu sparen: Es reicht die jeweilige ID für Amazon, iTunes, Spotify, etc. zu speichern. Der eigentlichen Link kann dann anhand der ID erstellt werden. Mit einer Amazon-ID kann dann beispielsweise sowohl zu Amazon-Music als auch zum Amazon Shop weitergeleitet werden.
Kids-Folgen fehlen
Ich biete ebenfalls alle Folgen den Drei Fragezeichen Kids an. Die sind ja aber, laut deiner Email, schon in Arbeit :-)
Zusammengefasst
Was sind deine Gedanken dazu? Ja/Nein/Vielleicht? Ich kann natürlich nur migrieren, wenn all diese Punkte geklärt sind. Ansonsten bleiben wir redundant und pflegen zwei mal die gleichen Daten. :D