GlobalObjects 'Product Backlog' erledigt

Auf dieser Seite werden behobene Fehler und Erweiterungen, mit der Angabe in welcher Version diese eingeflossen sind, angezeigt.

GlobalObjects Version 1.0.9

GlobalObjects; Es soll der std::unique_ptr als persistentes Attribut von persistenen Klassen ermöglicht werden

ID: 20240304_1
Typ: EXT
Nutzer/Rolle: Nutzer von GlobalObjects
Anforderung: Bislang konnte nur der std::shared_ptr als intelligenter zeiger genutzt werden. Es soll zusätzlich der std::unique_ptr als persistentes Attribut von persistenen Klassen ermöglicht werden.
Nutzen: Damit wird es möglich, std::unique_ptr als persistentes Attribut von persistenen Klassen zu verarbeiten.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn persisterne Klassen std::unique_ptr als persistentes Attribut nutzen können.
Status: Fertig für Version 1.0.9

GlobalObjects Version 1.0.8

GloExplorer, GloDeveloper; unter Linux kann kein externer Editor aufgerufen werden

ID: 20240208_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloExplorer und GloExplorer
Beschreibung: In den Settings kann in beiden Programmen ein externer Editor eingetragen werden, der z.B. bei Texteingaben alternativ zum Eintrag in das Textfeld aufgerufen werden kann. Dieses funktionierte unter Windows, aber nicht unter Linux.
Lösung: Der Aufruf von QProcess mit Aufruf des jeweiligen Editors in der Klasse EuQtExternPlainTextEditor wurde angepasst. Ursprünglich wurde der QProcess auf dem Stack angelegt und "verstarb" unter Linux zu schnell. Jetzt wird der QProcess als Member von EuQtExternPlainTextEditor geführt.
Status: Fehler behoben für Version 1.0.8

GloExplorer; gesetzte Notif-Farben werden für "Insert" und "DeleteInBase" nicht angewendet

ID: 20220514_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloExplorer
Beschreibung: In den Settings können Farbeinbstellungen für verschiedene Benachrichtigungen eingestellt werden. Wenn Objekte neu in den AllSet eingestellt oder aus dem AllSet gelöscht werden, werden die Einträge nicht berücksichtigt.
Lösung: Beim "Neu einstellen" wird jetzt mit dem farblichen Kennzeichnen gewartet, bis das Objekt in der AllSet-Darstellung angezeigt wird und beim "Löschen" wird vor dem Entfernen aus der AllSet-Darstellung die farblichen Kennzeichnen vorgenommen.
Status: Fehler behoben für Version 1.0.8

GloDeveloper; Settings speichert Textvorgaben nicht in UTF-8

ID: 20200704_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloDevelopers
Beschreibung: Wenn im GloDeveloper in den Programmeinstellungen Vorlagetexte eingegeben werden, werden Umlaute etc. nicht in UTF-8 in der GloDeveloper.ini gespeichert.
Problemumgehung: gefi.
Status: Fehler behoben für Version 1.0.8

GlobalObjects; In Transaktion erstmalig gespeicherte Objekte können nicht überwacht werden.

ID: 20240214_1
Typ: ERR
Nutzer/Rolle: Nutzer von GlobalObjects
Beschreibung: Da der glo::LockManager nur Objekte, welche in der Datenbank in Tabellen gespeichert sind, überwachen kann, werden Objekte, welche nur im Transaktionsspeicher sind, nicht berücksichtigt. Ein Überwachungsversuch wird mit Fehler quittiert.
Lösung: Es werden bei der Ermittlung der zu überwchenden Objekte zuerst die Objekte aus dem Transaktionsspeicher und dann erst die Objekte aus den Tabellen berücksichtigt.
Status: Fehler behoben für Version 1.0.8

GlobalObjects; In Transaktion erstmalig gespeicherte Objekte können nicht gesperrt werden.

ID: 20240212_1
Typ: ERR
Nutzer/Rolle: Nutzer von GlobalObjects
Beschreibung: Da der glo::LockManager nur Objekte, welche in der Datenbank in Tabellen gespeichert sind, sperren kann, werden Objekte, welche nur im Transaktionsspeicher sind, nicht berücksichtigt. Ein Sperrversuch wird mit Fehler quittiert.
Lösung: Es werden bei der Ermittlung der zu sperrenden Objekte zuerst die Objekte aus dem Transaktionsspeicher und dann erst die Objekte aus den Tabellen berücksichtigt.
Status: Fehler behoben für Version 1.0.8

GloDeveloper; bei Neuanlage von Tabellen werden die Dateien in den Verzeichnissen für externe Daten nicht gelöscht.

ID: 20240204_1
Typ: ERR
Nutzer/Rolle: Nutzer von GloDeveloper
Beschreibung: Wenn von GloDeveloper die Tabellen neu angelegt werden, werden bei nichtvorhandensein die Verzeichnisse für externe Daten anglegt. Bislang werden vorhandene externe Daten von alten Tabelleneinträgen nicht gelöscht. Dieses ist aber gefordert.
Lösung: Es werden bei vorhandensein von Verzeichnissen bei Neuanlage einer Tabelle alle darin vorhandnen Dateien gelöscht.
Status: Fehler behoben für Version 1.0.8

GlobalObjects; in einer Transaktion kann ein neues Objekt gespeichert, aber nicht in dieser Transaktion vor einem Commit gelöscht werden.

ID: 20240124_1
Typ: ERR
Nutzer/Rolle: Nutzer von GlobalObjects
Beschreibung: Wenn in einer Transaktion ein neues Objekt zum erstenmal gespeichert wird, kann es in der Transaktion vor deren Beendigung nicht mit ::deleteInBase() gelöscht werden.
Lösung: Der zu löschende Record hat z.B. bei Attributen des Typs std:.string ggf. einen Dateinamen, in dem der String gespeichert wird, noch nicht gesetzt. Der äquivalente Record wird also vor dem Löschen aus der Tabelle gelesen und konnte dann mit seinen referenzierten Dateien gelöscht werden. Nun werden aber in einer Transaktion zu speichernde Records bis zu einem Commit bzw. Abort im Transaktionsspeicher belassen. Damit scheitert natürlich das Löschen eines neuen Records, der noch nicht in der Tabelle vorliegt, weil das Lesen des äquivalente Records scheitert.
Es werden jetzt die zu ermittelnden Dateinamen z.B. der Stringdateien ermittelt, ohne einen Record aus der Tabelle zu lesen. Es wurde dafür die Methode

void Record::setDeterminedFileNamesForAllAttributesWithThese()

geschrieben, welche die ggf. nötigen Dateinamen in den jeweiligen Attributen setzt.
Status: Fehler behoben für Version 1.0.8

GloExplorer; nach Neuanlage kann kein Lock und Watch gesetzt werden

ID: 20240123_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloExplorer
Beschreibung: Bei Neuanlage eines Objektes kann kein Lock und Watch gesetzt werden, das ist ok so. Aber wenn gespeichert, sollten Auswahlen freigegeben werden.
Lösung: Nach dem Speichern wurden die entsprechenden Widgets aktiviert.
Status: Fehler behoben für Version 1.0.8

GloServer: Der GloServer stürzt ab, wenn ein Client eine Beobachtung auf das Sperren hat und der sperrende Client abstürzt

ID: 20240102_1
Typ: ERR
Nutzer/Rolle: Nutzer von GlobalObjects
Beschreibung: Wenn ein Client "A" eines GloServers eine Beobachtung z.B. auf das Freigeben einer Sperre gesetzt hat und dieses Objekt von einem anderen Client "B" gesperrt wird und dann dieser sperrende Client "B" abstürzt, wird bei der Erstellung der Benachrichtigung der automatischen Freigabe auf den abgestürzten Client (um seinen Namen und seine ID zu übermitteln) zugrgriffen; und der war schon tot ;-).
Lösung: Der Fehler wurde behoben, indem eine OrderMsg bei Referenz auf einen Client (Kommunikator) sich dessen Namen und ID kopiert. Es wird nur noch auf diese kopierten Daten zugegriffen, auch wenn der Client schon gestorben ist.
Status: Fertig für Version 1.0.8

GloExplorer: AllSet kennt keine geerbten Indexe

ID: 20231218_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloExplorers
Beschreibung: Wenn ein AllSet mit einem Index geöffnet wird, wird ein entsprechender Button angezeigt, mit dem ein AllSet sortiert und abfragbar über diesen Index geöffnet wird.
Das funktioniert nicht mit geerbten Indexen.
Lösung: Der Fehler wurde behoben. Hatte vielfältige Gründe in GlobalObjects wie auch im GloExplorer.
Status: Fertig für Version 1.0.8

GlobalObjects Version 1.0.7

GloDeveloper: Klasse als Bibliotheksklasse kennzeichnen

ID: 20190722_2
Typ: EXT
Nutzer/Rolle: Nutzer des GloDevelopers
Anforderung: Es soll möglich sein, mit dem GloDeveloper eine Klasse als Bibliotheksklasse kennzeichnen zu können. Für diese sollen dann keine Header- und Source-Dateien generiert werden.
Nutzen: Es wird die Wiederverwendung unterstützt.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn der entwickelnde Nutzer für jede persistente Klasse festlegen kann, ob für diese Header- und Source-Dateien generiert werden. Es wird dadurch realisiert, indem einfach kein Dateiname eingegeben wird, welches vorher nicht möglich war.
Status: Fertig für Version 1.0.7

GloDeveloper: Speicherleak

ID: 20200419_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloDevelopers
Beschreibung: Wenn im GloDeveloper in einem Projekt eine Base entfernt wird, verbleibt das Objekt vom Typ ProjectBase im Speicher.
Lösung: In int GloQtDeveloperProject::removeBaseProject( ProjectBase * pRemoveBaseProject ) wurde zwar pRemoveBaseProject aus der projektliste entfernt, aber nicht aus dem Speicher.
Dieses wurde jetzt implementiert.
Status: Fehler behoben für Version 1.0.7

GloDeveloper: Klassen auch ohne Dateinamen zulassen

ID: 20231213_1
Typ: EXT
Nutzer/Rolle: Nutzer des GloDevelopers
Anforderung: Bislang konnten persistente Klassen nicht ohne Dateinamen verarbeitet werden. Dieses soll sichergestellt werden und diese Klassen sollen im Developer durch ein anderes Icon erkennbar sein.
Nutzen: Damit persistente Klassen aus einer anderern Datenbak wieder verwendet werden können, ist es sinnvoll, die Header- und Source-Dateien nicht nochmals generieren zu lassen.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn persisterne Klassen ohne Dateinamen generiert und verarbeitet werden.
Status: Fertig für Version 1.0.7

GloDeveloper: kopieren einer Klasse mit Unterklassen kopiert nur erste Unterklassenebene

ID: 20210210_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloDevelopers
Beschreibung: Wenn im GloDeveloper eine Klasse mit Unterklassen, die wiederum Unterklassen haben, kopiert werden soll, werden nur die direkten Unterklassen, und nich der gesammte Ast, mitkopiert.
Lösung: In der Rekursion wurde die Information, dass "tief" kopiert werden soll, nicht übergeben; gefixt.
Status: Fehler behoben für Version 1.0.7

GloDeveloper: Drag & Drop von Attributen in einer Klasse lässt bewegte Attribute verschwinden

ID: 20231207_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloDevelopers
Beschreibung: Wenn im GloDeveloper in einer Klasse Attribute per Drag & Drop verschoben werden, verschwinden diese.
Lösung:

connect ( m_pTreeWidget_Attributes, SIGNAL( signal_ObjectDraged( QList *, Qt::DropAction ) ), this, SLOT( attributeListDraged( QList *, Qt::DropAction ) ) );

void GloQtDeveloperClassProp::init()

war doppelt implementiert. Dadurch zweimaliger Aufruf mit Verlust der Information, dass im selben TreeView verschoben wurde.
Status: Fehler behoben für Version 1.0.7

GlobalObjects Version 1.0.6

GlobalObjects; String-Index mit beschränkter Zeichenanzahl kann nicht gespeichert werden

ID: 20231108_1
Typ: ERR
Nutzer/Rolle: Nutzer von GlobalObjects
Beschreibung: Objekte mit einem Stringattribut mit beschränkter Länge, welches als Index genutzt wird, kann nicht gespeichert werden, wenn die erlaubte Stringlänge mit der eingestellten Indexstringlänge übereinstimmt.
Lösung:

std::string StringRecordAttribute::getValueAsString( const std::string & rsValue, bool bFillBlanks ) const

gefixt.
Status: Fehler behoben für Version 1.0.6

GlobalObjects Version 1.0.5

GlobalObjects; persistente Klassen mit Namespace

ID: 20230223_1
Typ: EXT
Nutzer/Rolle: Nutzer von GlobalObjects
Anforderung: Bislang können persistente Klassen nicht einem Namensraum zugeordnet sein. GlobalObjects mit den Tools soll persistente Klassen in einem Namensraum generieren und verarbeiten.
Nutzen: Damit wird es möglich, gleichnamige Klassen in unterschiedlichen Namensräumen mit GlobalObjects zu verarbeiten.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn persisterne Klassen in Namensräumen generiert und verarbeitet werden.
Status: Fertig für Version 1.0.5

GloDeveloper; Spracheinstellung für den Index wird nicht übernommen

ID: 20230223_2
Typ: ERR
Nutzer/Rolle: Nutzer des GloDevelopers
Beschreibung: Wenn für einen Index die Spracheinstellung ausgewählt wird, wird diese nicht übernommen.
Lösung: Es wurde der Sprachauswahl-Dialog mit "Qt::WA_DeleteOnClose" initialisiert. Dadurch waren die Daten des Dialogs nicht mehr vorhanden. Der Sprachauswahl-Dialog wird jetzt nach der Datenabfrage aus dem Speicher entfernt.
Status: Fertig für Version 1.0.5

GlobalObjects; es wird eine falsche Objektzuweisung zu einer datenbank nicht erkannt

ID: 20230106_1
Typ: ERR
Nutzer/Rolle: Nutzer von GlobalObjects
Beschreibung: Wenn zwei unterschiedliche Objekte in verschiedenen Datenbanken vorgehalten werden, kann es sein, dass diese jeweils die gleiche Klassen-ID haben.
Ein Anmelden eines als Typ nicht in einer DB vorhandenen Objekts gelingt desshalb fälschlicherweise, da nur auf die Klassen-ID geprüft wird. Es wird erst beim Speichern eine Exception geworfen.
Lösung: Es wird der Klassentyp in PrivateBase::assignObject(...) geprüft und bei einem falschen Typ ein entsprechender Fehler (glo::ERR_WRONG_BASE) retour geliefert.
Status: Fertig für Version 1.0.5

GlobalObjects Version 1.0.4

Notify für "Speichern" einleiten, ohne tatsächlich zu speichern

ID: 20220622_1
Typ: EXT
Nutzer/Rolle: Nutzer von GlobalObjects
Anforderung: Es soll für ein persistentes Objekt eine "WNM_WRITE"-Benachrichtigung initiiert werden können, ohne das betreffende Objekt speichern zu müssen.
Wenn ein Objekt 'A' ein anderes Objekt direkt referenziert, muss bei einer Referenzänderung das referenzierende Objekt 'A' gespeichert werden; das initiiert eine Benachrichtigung bei beobachtenden Instanzen, dass sich das Objekt 'A' geändert hat.
Referenziert aber Objekt 'A' ein anderes Objekt über ein Assoziationsklassen-Objekt, muss bei einer Referenzänderung nur das Assoziationsklassen-Objekt gespeichert werden. Damit die beobachtenden Instanzen des Objekts 'A' über die Referenzänderung informiert wird, soll beim speichern vom Assoziationsklassen-Objekt eine Benachrichtigung, dass sich Objekt 'A' geändert hat, initiiert werden können, ohne Objekt 'A' speichern zu müssen.
Nutzen: Ein unnötiges Speichern, nur um eine Benachrichtigzng zu initiieren, wird vermieden.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn eine "WNM_WRITE"-Benachrichtigung ohne wirklich zu speichern ausgelöst werden kann.
Status: Fertig für Version 1.0.4

GlobalObjects Version 1.0.3

GloExplorer, unspezifisches Verhalten bei Verbindungsabbruch zu einem GloServer

ID: 202202029_1
Typ: ERR
Nutzer/Rolle: Nutzer vom GloExplorer
Beschreibung: Wenn der GloExplorer eine Datenbank über den GloServer geöffnet hat, war das Verhalten des GloExplorers undefiniert, wenn es zu einem Abbruch der Verbindung zu dem GloServer kommt. Ab und an kam es zu einem Abstrurz wegen Zugriffs auf einen NULL-Pointer.
Lösung: EXT 20220307_1 realisiert und in den GloExplorer eingebaut.
Status: Fertig für Version 1.0.3

Verarbeitung von Verbindungsabbruch zu einem GloServer

ID: 20220307_1
Typ: EXT
Nutzer/Rolle: Nutzer von GlobalObjects
Anforderung: Bislang wurde ein Abbruch der Verbindung zwischen GlobalObjects-Clients und einem GloServer nur festgestellt, wenn der Client bei einem Zugriff auf den Server die entsprechende Fehlermeldung auswertete. Es soll aber möglich sein, über einen Verbindungsabbruch informiert zu werden.
Dieses wird über den "Persistente Objekte beobachten / benachrichtigen" Mechanismus realisiert.
Nutzen: Es kann auf einen Client/Server-Verbindungsabbruch unmittelbar reagiert werden.
Akzeptanzkriterien: S.o.
Status: Fertig für Version 1.0.3

GlobalObjects Version 1.0.2

GloDeveloper und GloExplorer; Umstellung auf Qt 6

ID: 20210126_1
Typ: EXT
Nutzer/Rolle: Nutzer des GloDevelopers und GloExplorer
Anforderung: Es wird die Gui jeweils auf Qt 6 portiert.
Nutzen: Anpassung an neue Entwicklung
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn die GUI des GloDeveloper und GloExplorer auf Qt 6 portiert ist.
Status: Fertig für Version 1.0.2

GloDeveloper, Speicher-Leck, wenn Projekt gespeichert wird

ID: 20211209_2
Typ: ERR
Nutzer/Rolle: Nutzer vom GloDeveloper
Beschreibung: Wenn das Projekt gespeichert wird, gibt es ein Speicher-Leck.
Lösung: In Methode int GloQtDeveloperProject::store() die erstellte Proektdatei wieder aus dem Speicher entfernt.
Status: Fertig für Version 1.0.2

GloDeveloper, Anzeige von Klassenauswahl zeigt immer Klassen-Icon für geöffnet an

ID: 20211209_1
Typ: ERR
Nutzer/Rolle: Nutzer vom GloDeveloper
Beschreibung: Es wird in der Baumansicht für die Auswahl von Oberklassen immer das Geöffnet-Icon angezeigt, auch wenn es nichts zu öffnen gab.
Lösung: In Methode void EuQtMoTreeWidgetItem::expandBranch() wird der Aufruf setExpanded(true) nur vorgenommen, wenn auch was zum Expandieren da ist.
Status: Fertig für Version 1.0.2

GlobalObjects Version 1.0.1

GlobalObjects, Umstellung von time_t auf std::time_t

ID: 20211102_2
Typ: EXT
Nutzer/Rolle: Nutzer von GlobalObjects
Anforderung: Umstellung des Typs time_t auf std::time_t.
Nutzen: Durch die Umstellung von time_t auf std::time_t wird eine bessere Kontinuität erreicht.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn alle GlobalObjects-Module auf std::time_t umgestellt sind.
Achtung: Es müssen in allen Schemadateien (*.ini) sämtliche Einträge "Type=time_t" in "Type=std::time_t" geändert werden, damit diese ohne Fehler gelesen werden können .
Status: Fertig für Version 1.0.1

Eine generierte, von glo::ObjCreator abgeleitete Klasse kann nur einmal mit #include eingebunden werden.

ID: 20211202_1
Typ: ERR
Nutzer/Rolle: Nutzer vom GloDeveloper
Beschreibung: Wenn eine, von glo::ObjCreator abgeleitete Klasse generiert wird, fehlen vor dem Kon- und Destruktor das Schlüsselwort 'inline'. Somit kann die Header-Datei nur einmalig eingebunden werden.
Lösung: Die Dateigenerierung in BaseMaker::generateObjCreator(...) angepasst.
Status: Fehler behoben für Version 1.0.1

GloDeveloper stürzt ab, wenn das glo::Persistent bearbeitet werden soll

ID: 20211130_1
Typ: ERR
Nutzer/Rolle: Nutzer vom GloDeveloper
Beschreibung: Wenn glo::Persistent bearbeitet werden soll, stürzt der GloDeveloper ab.
Lösung: Fälschlicherweise wurde die Abfrage, ob das zu bearbeitende Objekt vom Typs glo::Persistent ist (das hat Bearbeitungseinschränkungen und damit z.B. keine Toolbar für neue Attribute) auskommentiert (warum weiß der Geier). Abfrage wieder aktieviert.
Status: Fehler behoben für Version 1.0.1

GlobalObjects, Umstellung der Spy-Klassen von std::map auf std::unordered_map

ID: 20211126_1
Typ: EXT
Nutzer/Rolle: Nutzer von GlobalObjects
Anforderung: Umstellung der Klassen glo::CallBackSpy, glo::PersObjectSpy und glo::GenPersObjectSpy von std::map auf std::unordered_map.
Nutzen: Durch die Umstellung von std::map auf std::unordered_map wird ein Performance Gewinn erwartet.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn GlobalObject nach der Umstellung ohne Fehler ggf. etwas schneller läuft.
Status: Fertig für Version 1.0.1

GlobalObjects Version 1.0.0

Im GloDeveloper und GloExplorer über [Strg]+[F10] Kontextmenü aufrufbar machen

ID: 20210910_1
Typ: EXT
Nutzer/Rolle: Nutzer des GloDeveloper und GloExplorer
Anforderung: In TreeView-Anzeigen kann das Kontext-Menü nicht mit der üblichen Tastenkombination [Strg]+[F10] geöffnet werden.
Nutzen: Anwender die gerne mit der Tastatur arbeiten, sollen den Kontextmenü-Aufruf mit der üblichen Tastenkombination [Strg]+[F10] vornehmen können.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn alle TreeViews einen Kontextmenü-Aufruf mit der Tastenkombination [Strg]+[F10] vornehmen können.
Status: Fertig für Version 1.0.0

Wenn Objekt gespeichert wird, kann es nicht sofort wieder gelöscht werden

ID: 20210906_1
Typ: ERR
Nutzer/Rolle: Nutzer von GlobalObjects
Beschreibung: Wenn Objekt gespeichert wird, kann es nicht sofort wieder gelöscht werden, weil im Record die Dateipositionen der ObjID's in der m_TableObjIDMap nicht gesetzt sind. Erst nach einem refresh()!
Lösung: Es iwrd nach dem Speichern eines Datensatzes die FilePosition in den Result-Record übertragen.
Status: Fehler behoben für Version 1.0.0

GlobalObjects: Automatischer Aufruf von überschreibbaren Methoden vor und nach einem Persistent::refresh(), Persistent::lock(), Persistent::unlock(), Persistent::setWatch(...), Persistent::unsetWatch(...)

ID: 20210903_1
Typ: EXT
Nutzer/Rolle: Nutzer von GlobalObjects
Anforderung: Es soll vor und nach dem Wiedereinlesen eines Objektes, Sperren bzw. Freigeben und Überwachen eine überschreibbar Methode aufgerufen werden können. Es soll eine Datenübergabe von der erst aufgerufenen Methode zur zweit aufgerufenen Methode möglich sein.
Nutzen: Um nicht selbst die Methode glo::BasePersistent::refresh(), glo::BasePersistent::lock(), glo::BasePersistent::unlock(), glo::BasePersistent::setWatch(...) und glo::BasePersistent::unsetWatch(...) überschreiben zu müssen, rufen diese jeweils vor und nach ihrer Aktion eine überschreibbare Methode auf, die der Nutzer von GlobalObjects überschreiben kann.
Dort können ggf. notwendige zusätzliche Aktionen initiiert werden.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn die überschreibbaren Pre- und Post-Methoden aufgerufen werden.
Status: Fertig für Version 1.0.0

GlobalObjects Version 0.2.1 (2021.08.19 07:13)

GlobalObjects: TOndemand referenziert bei neuem Objekt keine Datenbank.

ID: 202108917_1
Typ: ERR
Nutzer/Rolle: Nutzer von GlobalObjects
Beschreibung: Wenn ein persistentes Objekt ein glo::TOndemand hat, und dieses zugewiesen wird, kann dieses nicht aus dem Ondemand-Zeiger geholt werden (ERR_NO_BASE). Grund ist, dass der Ondemand-Zeiger die Datenbank noch nicht kennt. Erst wenn das referenzierende Objekt aus der Datenbank geladen wird, kennt der Ondemand-Zeiger die Datenbank.
Lösung: Es wurde eine Methode postAssign(glo::Base & rBase) eingeführt, in der bei allen Referenzen, die die Datenbank kennen müssen, diese gesetzt wird.
Bei einem Aufruf von assign(glo::Base & rBase) wird postAssign(glo::Base & rBase) automatisch aufgerufen wird.
Status: Fehler behoben für Version 0.2.1 (2021.06.15 16:20)

GlobalObjects Version 0.2.0 (2021.08.10 14:45)

GloExplorer: Objekt mit mehreren Referenzen kann nicht gespeichert werden.

ID: 20210809_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloExplorer
Beschreibung: Objekt kann nicht gespeichert werden, wenn von zwei referenzierbaren Objekte das zweite refernziert wird.
Lösung: In int DataStreamer::streamAttributeListBlobInRecord(...) (in GloRecordAttributeFunctions.cpp) wurde die Analyse des Blobs für Referenzen geändert. Fehler war, dass bei Referenzen Abfragen des Inhalts stattfinden, die falsch waren. Bei einer Referenz, die auf etwas zeigt, sind z.B. Informationen über den Rekord des referenzierten Objekt in der XML-Datei. Wenn auf nichts gezeigt wird, dann fehlen diese Informationen. Gibt es nun nach der Referenz auf nichts eine weitere Referenz, die auf ein Objekt zeigt, wird die dortige Information gefunden.
Die oben genannte Methode bekommt eine Information, wie das Blob ausgewertet werden soll. Entweder wird eine Objekt-ID gesetzt oder ein ganzer Record erstellt. Diese Information wird in einem Fall nicht mehr genutzt, sondern es wird das Blob ausgewertet. Wenn es eine valide Objekt-ID ist, wird nur diese gesetzt. Ansonsten ggf. ein Record.
Status: Fehler behoben für Version 0.2.0 (2021.08.10 14:45)

GloExplorer: Wenn ein Objekt geändert wird, gibt es Speicher-Leaks.

ID: 20210707_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloExplorer
Beschreibung: Wenn ein Objekt über den GloQtExplorerGenericPersistentProp geändert wird, gibt es Speicher-Leaks.
Lösung: In void GloQtIntGenericPersistent::updateData() wird eine Liste von glo::BaseRecordAttribute geholt, bei denen der Referenzzähler inkrementiert wird.
Beim Einfügen in die GloQtIntGenericPersistent::m_AttributeList über void GloQtIntBaseRecordAttribute::setBaseRecordAttribute( glo::BaseRecordAttribute * pModelObject ) wird bei dem übergebenen glo::BaseRecordAttribute auch der Referenzzähler inkrementiert.
Der Referenzzähler vom geholten glo::BaseRecordAttribute wird nur bei Nichtzuweisung dekrementiert.
Das wurde geändert; der Referenzzähler vom geholten glo::BaseRecordAttribute wird in jedem Falls dekrementiert.
Status: Fehler behoben für Version 0.2.0 (2021.08.10 14:45)

GlobalObjects Version 0.1.9 (2021.06.15 16:20)

GlobalObjects: Wenn ein Objekt mehrmals aus einem AllSet geladen wird, gibt es Speicher-Leaks.

ID: 20210608_1
Typ: ERR
Nutzer/Rolle: Nutzer von GlobalObjects
Beschreibung: Wenn ein Objekt mehrmals aus einem AllSet geladen wird, gibt es Speicher-Leaks, aber nicht wenn Objekte mehrfach z.B. aus einem Ondemand geladen werden.
Lösung: Es wurde der geholte Record in einem AllSet nicht aus dem Speicher entfernt, wenn das Objekt schon existiert.
Status: Fehler behoben für Version 0.1.9 (2021.06.15 16:20)

GloExplorer: Explorer stürzt ab, wenn ein Objekt in Bearbeitung von anderen geändert oder gelöscht wird.

ID: 20210526_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloExplorer
Beschreibung: Ein Objekt im Bearbeitungsfenster wird von andern Client geändert. Nutzer bekommt eine Anzeige, ob er Daten übernehmen will. Wenn jetzt das Objekt von anderm Client gelöscht wird, bekommt der Nutzer die nächste Anzeige mit dem Angebot, das Bearbeitungsfenster zu schliessen. Tut er das, hat die erste Anzeige einen toten parent; das wars dann!
Lösung: Es werden vor dem Schliessen des Bearbeitungsfensters alle Anzeigen entfernt.
Status: Fehler behoben für Version 0.1.9 (2021.06.15 16:20)

GlobalObjects: Reference::getReference(BasePersistent*&) liefert bei keiner Referenz falschen Fehler-Code

ID: 20210423_1
Typ: ERR
Nutzer/Rolle: Nutzer von GlobalObjects
Beschreibung: Es wurd bei einer NULL-Referenz der Fehler "glo::ERR_NO_BASE" geliefert, erwartet wird der Fehler "glo::ERR_NO_REFERENCE".
Status: Fehler behoben für Version 0.1.9 (2021.06.15 16:20)

GlobalObjects: Refresh holt falsche Daten in Transaktion (nur wenn Local)

ID: 20210422_1
Typ: ERR
Nutzer/Rolle: Nutzer von GlobalObjects
Beschreibung: Wenn im Local-Mode (kein Server) wird bei einem Speichern in einer verschachtelten Transaktion nach dem Abbrechen der Transaktionen ein falscher Record aus dem Transaktionsmanager geholt.
Status: Fehler behoben für Version 0.1.9 (2021.06.15 16:20)

GlobalObjects: Automatischer Aufruf von überschreibbaren Methoden vor und nach Datenbankaktion

ID: 20210420_1
Typ: EXT
Nutzer/Rolle: Nutzer von GlobalObjects
Anforderung: Es soll vor und nach dem Speichern oder Löschen eines Objektes, jeweils eine überschreibbar Methode aufgerufen werden. Es soll eine Datenübergabe von der erst aufgerufenen Methode zur zweit aufgerufenen Methode möglich sein.
Nutzen: Um nicht selbst die Methode glo::BasePersistent::store(...) bzw. glo::BasePersistent::deleteInBase(...) überschreiben zu müssen, rufen diese jeweils vor und nach ihrer Aktion eine überschreibbare Methode auf, die der Nutzer von GlobalObjects überschreiben kann. Dort können ggf. notwendige zusätzliche Aktionen initiiert werden.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn die überschreibbaren Pre- und Post-Methoden aufgerufen werden.
Status: Fertig für Version 0.1.9 (2021.06.15 16:20)

GlobalObjects Version 0.1.8 (2021.03.31 15:32)

GloExplorer: Notify im Explorer verursacht ab und an Absturz wenn Objekt von anderm Client gelöscht.

ID: 20210322_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloExplorer
Beschreibung: Wenn ein Client über den GloServer ein Objekt löscht, können andere Clients darüber benachrichtigt werden. Wenn der GloExplorer über ein gelöschtes Objekt benachrichtigt wird und dieses anzeigt, stürzt der GloExplorer ab und an mit einer NULL-Poiner Exception ab.
Der Grund ist wahrscheinlich, dass auf das gelöschte Objekt, in diesem Fall das QTreeViewItem, nach dem Entfernen aus dem Speicher nochmals zugegriffen wird.
Lösung: Es wird zum Benachrichtigen über ein Qt-Signal z.Z. das zu entfernende QTreeViewItem versendet. Das soll in so weit geändert werden, dass nur noch die ObjID des betroffenen Objekts über das Signal versendet wird und die 'fangenden' Slots selbst das Objekt aus dem TreeView ermitteln. Wenn es dann nicht mehr vorhanden ist, auch gut.
Status: Fehler behoben für Version 0.1.8 (2021.03.31 15:32)

GlobalObjects: Container-Datei wird nicht gelöscht, wenn besitzendes Objekt gelöscht wird.

ID: 20210319_2
Typ: ERR
Nutzer/Rolle: Nutzer des GlobalObjects
Beschreibung: Wenn ein Objekt mit einem Container von Objekten gelöscht wird, muss die Container-Datei auch gelöscht werden. Dieses wird aber nicht durchgeführt.
Lösung: Die Methode TableWriterInterface::deleteObjectData(…) wurde entsprechend angepasst.
Status: Fehler behoben für Version 0.1.8 (2021.03.31 15:32)

GlobalObjects: Container-Datei wird nicht gelöscht, wenn leer.

ID: 20210319_1
Typ: ERR
Nutzer/Rolle: Nutzer des GlobalObjects
Beschreibung: Wenn ein Objekt mit einem Container von Objekten gespeichert wird, wird dieser Container als Datei gespeichert. Wenn der Container geleert wird, und das Objekt wiederum gespeichert wird, sollte die Container-Datei gelöscht werden. Dieses wird aber nicht durchgeführt.
Lösung: In der Methode TableWriterInterface::updateInsert(…) wird für die Container-Attribute die Methode LotRecordAttribute::getFormattedFieldContents(…) aufgerufen. Diese war fehlerhaft und wurde angepasst.
Status: Fehler behoben für Version 0.1.8 (2021.03.31 15:32)

GlobalObjects Version 0.1.7 (2021.03.05 09:11)

GlobalObjects: Einzelreferenzen wie Pointer, eingebettet oder std::shared_ptr werden über den Server nicht gespeichert!

ID: 20210215_1
Typ: ERR
Nutzer/Rolle: Nutzer von GlobalObjects
Beschreibung: Es werden Speicherversuche von Objekten mit einer Refernz auf ein anderes Objekt mit Fehlermeldung ERR_NO_CORRECT_STREAM_DATA abgewiesen.
Lösung: Daten wurden nicht in das Übertragungs-XML eingefügt. Wurde repariert.
Status: Fehler behoben für Version 0.1.7 (2021.03.05 09:11)

GlobalObjects Version 0.1.6 (Jan 25 2021)

GlobalObjects, beim Speichern eines Objekt mit Sets bzw. Listen von pers. Objekten, werden die Referenzen verdoppelt.

ID: 20210107_1
Typ: ERR
Nutzer/Rolle: Nutzer von GlobalObjects
Beschreibung: In der Datenbank wurden die Einträge der Referenzen verdoppelt, ein Löschen war nicht mehr möglich
Lösung: Fehler in der Unterscheidung von pers. Objekten und generischen pers. Objekten behoben. Es wurde bei pers. Objekten die Attribute von gen.pers. Objekten mitverarbeitet.
Status: Fehler behoben für Version 0.1.6 (Jan 25 2021)

GloExplorer, Fehler im Kontextmenü des Auswahldialogs für referenzierte persistente Objekte.

ID: 20201107_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloExplorers
Beschreibung: Das Kontextmenü des Auswahldialogs für referenzierte persistente Objekte zeigt die Einträge nur lehr, ohne Bezeichnung an.
Lösung: Die Methode zur Anzeige der Einträge (wegen Sprachumschaltung) wurde nie aufgerufen. Somit blieben die Menüeintäge ohne Beschriftung.
Status: Fehler behoben für Version 0.1.6 (Jan 25 2021)

GloExplorer. Im Objektbearbeitungsdialog reagieren die Buttons [Refresh], [Speichern], [OK] oder [Abbrechen] nicht auf Tastatur.

ID: 20201109_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloExplorers
Beschreibung: Die oben genannten Buttons können zwar mittesl [TAP] selektiert werden, reagieren aber nicht auf die anschliessende [ENTER]-Taste.
Lösung: Wurden im Qt Designer auf 'autodefault' gesetzt.
Status: Fehler behoben für Version 0.1.6 (Jan 25 2021)

GlobalObjects Version 0.1.5

GloExplorer, Referenz eines Objektes auf ein anderes Objekt kann nicht entfernt werden

ID: 20201007_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloExplorers
Beschreibung: Referenz eines Objektes auf ein anderes Objekt kann, nur im Serverbetrieb, nicht entfernt werden.
Lösung: Das Problem lag in der Klase GloAPointerRecordAttribute, die bei Zugehörigkeit zu einem generischen Objekt (GloGenericPersistent) zusätzlich zum GloRecord einen Zeiger auf das referenzierte GloGenericPersistent hat. Der wurde beim Setzten des Referenzwertes auf NULL nicht entfernt und beim Verpacken für das TCP-Packet mit übertragen.
Status: Fehler behoben für Version 0.1.5

GloServer, Absturz beim Speichern von nicht generischen Objekten mit Referenzen auf andere Objekte

ID: 20200824_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloServers
Beschreibung: Nicht generische Objekte werden über den GloServer nicht gespeichert, der GloServer stürzt ab. Das XML-Datenpacket ist fehlerhaft.
Lösung: Das XML-Datenpacket wird angepasst.
Status: Fehler behoben für Version 0.1.5

GloDeveloper, Datenbank mehrfach referenziert

ID: 20200728_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloDevelopers
Beschreibung: Es kann eine Datenbank mehrmals in ein Projekt übernommen werden, was nicht sinnvoll ist.
Lösung: Es wurde beim Einfügen einer Base nicht geprüft, ob diese schon im Projekt ist. Dieses wurde jetzt implementiert.
Status: Fehler behoben für Version 0.1.5

GloServer Absturz

ID: 20200504_1
Typ: ERR
Nutzer/Rolle: Nutzer des GloServers
Beschreibung: Wenn eine leerer Menge, abgeleitet von GloBaseLot, gelockt werden soll, stürzt der GloServer ab.
Lösung: Bei der Tcp-Übertragung wurde eine leere Menge als 0 übertragen und dann darauf als std::list zugegriffen! Wurde behoben.
Status: Fehler behoben für Version 0.1.5

GloDeveloper ins englische übersetzen

ID: 20180919_3
Typ: EXT
Nutzer/Rolle: Nutzer des GloDevelopers
Anforderung: Es soll die GUI des GloDeveloper mittels des Qt-Linguist ins englische übersetzt werden.
Nutzen: Es soll der GloDeveloper für englischsprachige Nutzer zugänglich sein.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn der GloDeveloper eine englische GUI hat.
Status: Fertig für Version 0.1.5

GloExplorer ins englische übersetzen

ID: 20180919_6
Typ: EXT
Nutzer/Rolle: Nutzer des GloExplorer
Anforderung: Es soll die GUI des GloExplorer mittels des Qt-Linguist ins englische übersetzt werden.
Nutzen: Es soll der GloExplorer für englischsprachige Nutzer zugänglich sein.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn der GloExplorer eine englische GUI hat.
Status: Fertig für Version 0.1.5

GlobalObjects Header-Dokumentation ins englische übersetzen

ID: 20200330_1
Typ: EXT
Nutzer/Rolle: Nutzer von GlobalObjects
Anforderung: Es soll die Dokumentation in den Headern für doxygen in die englische Sprache übersetzt werden.
Nutzen: Es soll GlobalObjects für englischsprachige Nutzer des GloDevelopers zugänglich sein.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn die gesamte Dokumentation in den Headern für doxygen in englischer Sprache vorliegt.
Status: Fertig für Version 0.1.5

GlobalObjects Handbücher ins englische übersetzen

ID: 20200330_2
Typ: EXT
Nutzer/Rolle: Nutzer von GlobalObjects
Anforderung: Es soll die Dokumentation in den Handbüchern in die englische Sprache übersetzt werden.
Nutzen: Es soll GlobalObjects für englischsprachige Nutzer des GloDevelopers zugänglich sein.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn die gesamte Dokumentation in den Handbüchern in englischer Sprache vorliegt.
Status: Fertig für Version 0.1.5

GlobalObjects Version 0.1.4

GlobalObjects an Visual Studio 2019 anpassen und ausliefern

ID: 20200307_1
Typ: EXT
Nutzer/Rolle: Entwickelnder Nutzer von GlobalObjects
Anforderung: Es soll ermöglicht werden, GlobalObject voll umfänglich mit VS 2019 zu nutzen.
Nutzen: Anpssaung von GlobalObjects an die neueset C++ IDE von Microsoft.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn GlobalObjects mit allen Tools in Verbindung mit VS 2019 funktioneiert.
Status: Fertig für Version 0.1.4

GlobalObjects an Visual Studio 2019 anpassen; es hagelt Fehler

ID: 20200317_1
Typ: ERR
Nutzer/Rolle: Entwickelnder Nutzer von GlobalObjects
Beschreibung: Bei Kompilierung mit Visual Studio 2019 werden Fehler bezüglich "xstring" wegen Nutzung eines unbekannten Typs geworfen.
Lösung: In 'GloObjID.h' 'sstream' eingebunden.
Status: Fehler behoben für Version 0.1.4

Index wirde falsch ausgewertet

ID: 20200112_1
Typ: ERR
Nutzer/Rolle: Entwickelnder Nutzer von GlobalObjects
Beschreibung: Bei Übergebe eines Indexes an einen AllSet wird nicht das erwartetet Ergebnis geliefert.
Status: Fehler behoben für Version 0.1.4

Wenn mehrere Clients im Mehrbenutzerbetrieb viele Daten einlesen, bleibt der Server irgendwann stehen

ID: 20200314_1
Typ: ERR
Nutzer/Rolle: Entwickelnder Nutzer von GlobalObjects
Beschreibung: Der Server bleibt in einer Endlosschleife 'hängen', wenn viele Anfragen eintreffen.
Status: Fehler behoben für Version 0.1.4

GlobalObjects Version 0.1.3

Index mit einem Attribut aus Oberklasse stürzt ab

ID: 20190722_4
Typ: ERR
Nutzer/Rolle: Entwickelnder Nutzer von GlobalObjects
Beschreibung: Wenn im AllSet ein Filter von einem Index gesetzt wird, der ein Attribut aus der Oberklasse hat, stürzt die Anwendung ab.
Status: Fehler behoben für Version 0.1.3

Index mit Integer funktioniert nicht als Filter

ID: 20190727_1
Typ: ERR
Nutzer/Rolle: Entwickelnder Nutzer von GlobalObjects
Beschreibung: Wenn im AllSet ein Filter von einem Index, der ein Integer ist, gesetzt wird, wird beim Iterieren kein Objekt gefunden, obwohl Eingabe stimmt.
Status: Fehler behoben für Version 0.1.3

GlobalObjects Version 0.1.2

time_t wird aus Datenbank falsch ermittelt

ID: 20190716_1
Typ: ERR
Nutzer/Rolle: Entwickelnder Nutzer von GlobalObjects
Beschreibung: Es soll beim Einlesen von Objekten aus GlobalObjects ein ggf. vorhandenes Attribut vom Typ 'time_t' die richtig lokalisierte Zeit ermittelt werden (z.Z. wird die Uhrzeit um 2 Stunden versetzt ermittelt).
Status: Fehler behoben für Version 0.1.2

GlobalObjects Version 0.1.1

Index im GloDeveloper erstellen

ID: 20181007_1
Typ: EXT
Nutzer/Rolle: Entwickelnder Nutzer von GlobalObjects
Anforderung: Es soll ermöglicht werden, im GloDeveloper für eine persistente Klasse einen Index aus seinen Attributen zu definieren.
Um das Finden von Objekten in der Objektdatenbank zu beschleunigen, sind jetzt schon alle Objekte automatisch über eine GloObjID indiziert. Zusätzlich sollen für jede persistente Klasse Indexe aus deren Attributen, auch geerbeten und Attributen aus referenzierten Klassen definiert werden können.
Nutzen: Wenn ein Index definiert werden kann, kann GlobalObjects in soweit erweitert werden, um diesen Index zu erstellen.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn im Datenbankschema ein Index definiert ist.
Status: Fertig für Version 0.1.1

Index im Schema auswerten und speichern

ID: 20181007_2
Typ: EXT
Nutzer/Rolle: Entwickelnder Nutzer von GlobalObjects
Anforderung: GlobalObjects soll insoweit erweitert werden, dass es die Indexinformation auswerten kann, und wenn ein entsprechendes Objekt gespeichert bzw. gelöscht wird, diesen aktualisiert.
Nutzen: Wenn ein Index erstellt werden kann, können mittels diesen Objekte schnell gefunden werden. Zusätzlicher Nutzen ist gegeben, wenn der Index in einem AllSet als Filter genutzt werden kann.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn beim speichern bzw. löschen eines Objektes der Index aktualisiert ist.
Status: Fertig für Version 0.1.1

Index im AllSet als Filter auswerten

ID: 20181007_3
Typ: EXT
Nutzer/Rolle: Entwickelnder Nutzer von GlobalObjects
Anforderung: GloBaseAllSet und GloTAllSet sollen insoweit erweitert werden, dass es möglich ist, einen Filter zu setzen. In der ersten Ausführung werden folgende Filter eingebaut:
1. Es soll ein Suchstring ggf. mit Platzhaltern '*' und '?', welche bei der Auswertung berücksichtigt werden, übergeben werden können. z.B. soll der Suchstring "H*|Me?er" alle 'Meier', 'Meyer' bzw 'Meger' deren Vorname mit einem 'H' anfängt, vom AllSet beim Iterieren geliefert werden.
2. Es soll ein Suchstring und Vergleichsoperator übergeben werden können. Wenn z.B. der Suchstring den Wert "123" und der Vergleichsoperator den Wert '<'' hat, werden alle Objekte mit dem Index kleiner 123 geliefert.
3. Es sollen zwei Suchstrings, ein Start- und ein Endwert übergeben werden können. Es sollen nur die Objekte geliefert werden, deren Index '>=' dem Startwert und '<=' dem Endwert sind.
Nutzen: Es muss nicht eine dedizierte Indexabfrage abgeschickt werden, sondern der AllSet liefert die gewünschten Objekte.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn der AllSet alle Filter beim Iterieren berücksichtigt.
Status: Fertig für Version 0.1.1

Indexabfrage im AllSet ermöglichen

ID: 20181007_4
Typ: EXT
Nutzer/Rolle: Entwickelnder Nutzer von GlobalObjects
Anforderung: GloBaseAllSet und GloTAllSet sollen insoweit erweitert werden, dass es möglich ist, eine Indexabfrage aufzurufen. In der ersten Ausführung werden folgende Indexaufrufe eingebaut:
1. Es soll ein Suchstring ggf. mit Platzhaltern '*' und '?', welche bei der Auswertung berücksichtigt werden, übergeben werden können. z.B. soll der Suchstring "H*|Me?er" alle 'Meier', 'Meyer' bzw 'Meger' deren Vorname mit einem 'H' anfängt, vom AllSet geliefert werden.
2. Es soll ein Suchstring und Vergleichsoperator übergeben werden können. Wenn z.B. der Suchstring den Wert "123" und der Vergleichsoperator den Wert '<'' hat, werden alle Objekte mit dem Index kleiner 123 geliefert.
3. Es sollen zwei Suchstrings, ein Start- und ein Endwert übergeben werden können. Es sollen nur die Objekte geliefert werden, deren Index '>=' dem Startwert und '<=' dem Endwert sind. 4. Es wird ermöglicht, Indexabfrage auch für 'geerbte' Indexe abzusetzen.
Nutzen: Es können Objekte anhand ihres Indexes schnell gefunden werden, ohne durch den AllSet iterieren zu müssen.
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn der AllSet alle aufgeführten Indexabfragen ermöglicht.
Status: Fertig für Version 0.1.1