Persistenz Framework für die Rollen-basierte Programmiersprache SCROLL (SCala ROLes Language)
Siehe Wiki für API und Dokumentation:
- Wiki von SCROLL (SCROLL selbst, Grundlegendes, externes Repository)
- Wiki von SCROLL-persistence (Persistierung von SCROLL, dieses Repository)
Dem Projekt liegen zwei Beispiele im Ordner /src/main/scala/scroll/examples
bei:
UniversityExample_small
Ein kleines Beispiel einer Universität. Sehr übersichtlich und gut für Einsteiger.UniversityExample_large
Ein größeres Beispiel einer Universität. Komplexer und gut für Fortgeschrittene.
Jeder, der gerne an der Weiterentwicklung mitwirken möchte, möge sich einfach bei mir melden. (Github Issue, E-Mail, ...)
Durchgestrichene Features wurden bewusst nicht entwickelt. Dies kann einen von folgenden zwei Gründen haben, was jedoch dokumentiert hinter den entsprechenden Einträgen steht:
- Feature nicht möglich aufgrund fehlender Informationsstrukturen des zugrunde liegenden Frameworks
SCROLL
. Mehr dazu in der Wiki unterGrundlage
->Grundregel
- Feature nicht notwendig, da ...
- es aus mehreren anderen zusammengesetzt werden kann und daher nicht Atomar und notwendig ist
- es gegen den Grundgedanken der rollenbasierten Welt arbeitet
- es sich um Feature-Creep handelt
- ...
-
Konzeption und Klassenentwurf, Ergebnis: Klassendiagramm
-
Einbetten von Hibernate in das Projekt, inklusive Session Management
-
Implementieren der Klassen für die Abbildung der Persistenz
-
Reflection und Serializer programmieren -> Example Entitäten aufsplitten, Variablen mit Werten ermittelbar
-
Herangehensweise, Ausprobieren von verschiedenen Ansätzen
- Primitives Laden von NTs, alle auf ein Mal, Variablen Mapping nur über vorherige Angabe
- Komplexes Laden von NTs, konkrete Ergebnisse zurück geben (Abfrage nach Values), Variablen Mapping automatisiert
-
NT
-
NT INSERT / UPDATE
- NT speichern/updaten, RT Playing ignorieren, keine Duplikatserkennung semantisch gleicher Instanzen
- NT speichern/updaten, RT Playing ignorieren, Duplikatserkennung semantisch gleicher Instanzen
-
NT speichern/updaten, RT Playing mit speichern/updaten
In SCROLL erhält man von einem NT ausgehend nicht die gespielten RT.
-
NT SELECT
- NT laden, RT Spielpartner ignorieren
-
NT laden, RT Spielpartner mit laden, ohne Played-By Beziehung in Realanwendung
Müsste für jeden zu ladenden RT auch den containing CT kennen, was unbegrenzt viele sein könnten. Zudem soll im rollenbasierten Grundgedanken ein NT keine Aktionen auf RTs ausüben können. Auch kommt man in SCROLL von einem NT nicht auf seine playing RTs und der Konsistenz wegen hier im persistence Modell auch nicht. Außerdem eine Kombination aus anderen Features. -
NT laden, RT Spielpartner mit laden, mit Played-By Beziehung in Realanwendung
Analog zum vorherigen Punkt
-
NT DELETE
- NT löschen, RT Played-By Beziehungen ignorieren, RT Spielpartner ignorieren
- NT löschen, RT Played-By Beziehungen mit löschen, RT Spielpartner ignorieren
-
NT löschen, RT Played-By Beziehungen mit löschen, RT Spielpartner mit löschen
Im rollenbasierten Grundgedanken soll ein NT keine Aktionen auf RTs, die er spielt, ausüben können. Außerdem eine Kombination aus anderen Features.
-
-
RT
-
RT INSERT / UPDATE
- RT speichern/updaten, NT/CT Player ignorieren, keine Duplikatserkennung semantisch gleicher Instanzen
- RT speichern/updaten, NT/CT Player ignorieren, Duplikatserkennung semantisch gleicher Instanzen
- RT speichern/updaten, NT/CT Player mit speichern/updaten
- RT speichern/updaten, enthaltener CT mit speichern/updaten
-
RT SELECT
- RT laden, NT/CT Spielpartner ignorieren
- RT laden, NT/CT Spielpartner mit laden, ohne Played-By Beziehung in Realanwendung
- RT laden, NT/CT Spielpartner mit laden, mit Played-By Beziehung in Realanwendung
-
RT DELETE
- RT löschen, Played-By Beziehungen ignorieren, NT/CT Spielpartner ignorieren
- RT löschen, Played-By Beziehungen mit löschen, NT/CT Spielpartner ignorieren
-
RT löschen, Played-By Beziehungen mit löschen, NT/CT Spielpartner mit löschen
Eine Kombination aus anderen Features.
-
-
CT
-
CT INSERT / UPDATE
- CT speichern/updaten, RT Playing ignorieren, keine Duplikatserkennung semantisch gleicher Instanzen
- CT speichern/updaten, RT Playing ignorieren, Duplikatserkennung semantisch gleicher Instanzen
-
CT speichern/updaten, RT Playing mit speichern/updaten
In SCROLL erhält man von einem CT ausgehend nicht die gespielten RT - CT speichern/updaten, enthaltene RT mit speichern/updaten, NT/CT Player dieser RT nicht mit speichern/updaten
- CT speichern/updaten, enthaltene RT mit speichern/updaten, NT/CT Player dieser RT mit speichern/updaten
-
CT SELECT
- CT laden, RT Spielpartner ignorieren
-
CT laden, RT Spielpartner mit laden, ohne Played-By Beziehung in Realanwendung
Müsste für jeden zu ladenden RT auch den containing CT kennen, was unbegrenzt viele sein könnten. Zudem soll im rollenbasierten Grundgedanken ein CT keine Aktionen auf RTs ausüben können. Auch kommt man in SCROLL von einem CT nicht auf seine playing RTs und der Konsistenz wegen hier im persistence Modell auch nicht. Außerdem eine Kombination aus anderen Features. -
CT laden, RT Spielpartner mit laden, mit Played-By Beziehung in Realanwendung
Analog zum vorherigen Punkt -
CT laden, enthaltene RTs mit laden, Spielpartner dieser RTs ignorieren
SCROLL selbst ermöglicht es nicht, RTs ohne Spielpartner in einen CT einzufügen, daher geht das leider nicht - CT laden, enthaltene RTs mit laden, Spielpartner dieser RTs mit laden
-
CT DELETE
- CT löschen, RT Played-By Beziehungen ignorieren, RT Spielpartner ignorieren
- CT löschen, RT Played-By Beziehungen mit löschen, RT Spielpartner ignorieren
-
CT löschen, RT Played-By Beziehungen mit löschen, RT Spielpartner mit löschen
Im rollenbasierten Grundgedanken soll ein CT keine Aktionen auf RTs, die er spielt, ausüben können. Außerdem eine Kombination aus anderen Features. - CT löschen, enthaltene RT mit all deren Played-By Beziehungen zu anderen löschen, Spielpartner ignorieren
-
CT löschen, enthaltene RT mit all deren Played-By Beziehungen zu anderen löschen, Spielpartner mit löschen
nicht implementieren, da bei RT DELETE Spielpartner auch nicht mit gelöscht werden und es hier dann inkonsequent wäre.
-
-
Massenoperationen (Annäherung an
alles speichern
undalles laden
)-
von der globalen Ansicht ausgehend
-
alle CT speichern/updaten, dabei auch alle enthaltenen RT, alle Spielbeziehungen, ...
nicht möglich, da es in SCROLL selbst keine Möglichkeit gibt, alle CTs zu erhalten. - alle CT laden, dabei auch alle enthaltenen RT, alle Spielbeziehungen, ...
-
-
von einem CT ausgehend
- einen CT übergeben, diesen speichern/updaten, dabei alles persistieren, an das man dabei irgendwie ran kommt (enthaltene CT, deren Spieler, ...)
Alternative, da alle CT speichern/updaten nicht geht, siehe Problem oben. -
einen CT laden, alles herausziehen, an das man dabei irgendwie ran kommt
Redundant, da ohne großen Aufwand für einen Entwickler später selbst möglich zu implementieren, da das normale Laden eines CT schon alles nötige bereitstellt. Zudem gefährlich, da nur Teilansichten geladen werden und ein wirklichesalles laden
(siehe oben) mehr Sinn macht.
- einen CT übergeben, diesen speichern/updaten, dabei alles persistieren, an das man dabei irgendwie ran kommt (enthaltene CT, deren Spieler, ...)
-