• Es freut uns dass du in unser Minecraft Forum gefunden hast. Hier kannst du mit über 130.000 Minecraft Fans über Minecraft diskutieren, Fragen stellen und anderen helfen. In diesem Minecraft Forum kannst du auch nach Teammitgliedern, Administratoren, Moderatoren , Supporter oder Sponsoren suchen. Gerne kannst du im Offtopic Bereich unseres Minecraft Forums auch über nicht Minecraft spezifische Themen reden. Wir hoffen dir gefällt es in unserem Minecraft Forum!

API zum Speichern von Spielereinstellungen

BloodSKreaper

Vorarbeiter
Mitglied seit
12 Oktober 2014
Beiträge
248
Diamanten
12
Minecraft
BloodSKreaper
Guten Abend,

derzeit stehe ich vor dem Problem, dass ich mehrere Plugins habe, die für sich jeweils Spielereinstellungen speichern. Da hier jedes mal eine eigene Implementierung zur Speicherung von diesen Daten nötig wird, würde ich gerne eine API benutzen, die die Speicherung von diesen Daten übernimmt. So soll jedes Plugin die Daten nurnoch über diese API speichern, wodurch diese Einstellungen erstens an einem zentralen Ort sind und Änderungen an der Speicherung nur in der API vorgenommen werden müssen. Hier die Frage, wie ich das am Besten realisiere. Ich hätte ein Plugin entworfen, das die Daten in einer Datenbank speichert. Dies sollte in etwa so aussehen. settings(player_UUID, key, value). Benötigt ein Plugin einen Wert von der API, so wird dieser beim ersten Mal aus der Datenbank gelesen und im RAM zwischengespeichert. Wird ein Wert geschrieben, so wird dieser im RAM gespeichert, sowie asynchron in die Datenbank geschrieben.

Jetzt zu meiner eigentlichen Frage:
Die API soll mit mehreren Datentypen arbeiten können. In MySQL kann die Spalte value aber nur einen Datentyp annehmen. Wie könnte ich dieses Problem elegant lösen, oder gibt es gar eine bessere Herangehensweise an das grundlegende Problem als meine beschriebene?

Freundliche Grüße
BloodSKreaper
 

UnityGaming

Workaholic
Mitglied seit
25 Oktober 2015
Beiträge
516
Alter
20
Diamanten
2
Minecraft
FastFelix771
Die API soll mit mehreren Datentypen arbeiten können. In MySQL kann die Spalte value aber nur einen Datentyp annehmen. Wie könnte ich dieses Problem elegant lösen
Elegant sei mal dahingestellt, aber du könntest die Werte als BINARY / TINYBLOBs speichern, wenns unbedingt MySQL sein muss.
Oder du serialisierst die Werte vorher und kodierst sie in z.B. Base64 und speicherst das dann als VARCHAR. Hast dann eben den Serialisierungsaufwand mit dran.
Da die Settings ja eher kleine Werte sein werden, dürftest du damit auch keine Limits überschreiten bzgl. der Spaltenlänge beim varchar.

oder gibt es gar eine bessere Herangehensweise an das grundlegende Problem als meine beschriebene?
Falls dir eine NoSQL Datenbank zur Verfügung steht, hättest du damit weniger Stress, meiner Meinung nach.
Wenn du es auf Performance / Latenz anlegst, wäre Redis eine schöne Idee zum Beispiel. Schenkst dir sogar das Caching, je nachdem wo dein Redis Server liegt.

Was die Settings an sich betrifft, als kleine Anmerkung, du könntest dir das manuelle Caching im RAM sowieso schenken und die vorhandene Player Metadata API dafür nutzen.
Diese kannst du beim JoinEvent aus der Datenbank befüllen, beim QuitEvent zurückschreiben in die DB und bei Nutzung der API schreibst du im Hintergrund bloß in die Player Metadata.
 
D

deleted223309

Guest
Spricht denn irgendwas gegen JPA? Ich mein dafür ist das Ding ja da.
 

UnityGaming

Workaholic
Mitglied seit
25 Oktober 2015
Beiträge
516
Alter
20
Diamanten
2
Minecraft
FastFelix771
Was ist das? Ich finde dazu nicht wirklich etwas.
https://bukkit.org/threads/tutorial-metadata-what-it-is-and-how-to-use-it.276338/
Der Beitrag ist zwar alt, aber immer noch gültig. (Sofern die API nach der 1.12.2 nicht abgeändert wurde)

Spricht denn irgendwas gegen JPA? Ich mein dafür ist das Ding ja da.
Für die Kleinigkeit gleich ein ORM auffahren?
Von abgesehen, dass man damit dann neue Tore zur Hölle öffnet. :3
 

UnityGaming

Workaholic
Mitglied seit
25 Oktober 2015
Beiträge
516
Alter
20
Diamanten
2
Minecraft
FastFelix771
D

deleted223309

Guest
Ob sich der Mehraufwand für das bisschen mehr Komfort am Ende lohnt, wage ich anzuzweifeln.
Es geht dabei nicht um Komfort. OP sucht nen Persistence Layer für seinen Server. Genau das ist was JPA bereitstellt. Warum also selbst was stricken? Unnötiger Mehraufwand! Warum das jetzt plötzlich ein Tor zur Hölle sein soll versteh ich auch nicht. Ich arbeite damit täglich und das in kritischeren Projekten als nem MinecraftServer.
 
Oben