Application Commands Part 4: Stateful Commands

[diewellenlaenge]

Bedingungen

• Bitte zu erst die Application Commands Übersicht lesen (Application Commands Part 0: Übersicht #114)
• Geblockt von der Messagehandler-Bridge Application Commands Part 3: Messagehandler-Bridge #117 (das muss zu erst erledigt werden)

Beschreibung

Damit das volle Potential von Application Commands genutzt werden kann, sollten die Module irgendwie mit States umgehen können. Dies ist beispielsweise notwendig für anonyme Polls oder Woisgang-Abfragen. Bisher bastelt jedes Modul sich seinen eigenen temporären Store. Das ist kacke, weil der verloren geht, wenn der Bot neustartet.

Todos

• Konzept ausarbeiten (bisher existiert dazu noch nichts)
• Irgendwie versuchen, das mit Sequelize o. ä. zu lösen, damit der State auch einen Restart überlebt
• Das irgendwie versuchen, generisch zu halten, sodass jedes Modul sich einen eigenen State bauen kann

[twobiers]

Spontaner Gedanke den ich eben Festhalten will. Ist nicht durchdacht, kam mir nur spontan in den Sinn:

Möglichkeit eines Key Value Stores jedes Modul hat unter einem eindeutigen Key einen Store, in dem dieses Modul ein Objekt ablegen kann.
Mögliche Problematiken: Migrationen, NoSQL, SQLite

[twobiers]

Ich hab drüber nachgedacht und nochmal ein wenig rumgespielt. Finde wir sind so wie die Module Sequelize bisher verwenden ist es am sinnvollsten. Wir fahren über die Model-Extension ein schönes Active-Record Pattern und brauchen da eigentlich keine weitere Abstraktion. Die würde alles nur verkomplizieren. Habe überlegt ob es sinnvoll wäre Repository-Pattern zu integrieren, aber das schafft wieder mehr Probleme als es uns nützt. So sind wir schon auf einem guten Weg.

Das einzige was wir mMn. machen sollten ist Punkt 1 auf der Liste. Sprich: Wir definieren wie der Storage verwenden werden sollte.