GlobalObjects 101158Anov24
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.1.2
GloExplorer; Ein neues Bearbeitungsfenster in der Mitte des MDI anzeigen.
ID: 20240917_4Typ: EXT
Benutzer/Rolle: GloExplorer-Benutzer
Beschreibung: Derzeit wird irgendwo ein Objektbearbeitungsfenster angezeigt und muss dann oft in den Arbeitsbereich gezogen werden.
Nutzen: Ein bisschen Unbill abbauen.
Lösung: Mit vertretbarem Aufwand ließe sich zumindest ein neues Bearbeitungsfenster in der Nähe des Mauszeigers positionieren.
Status: Fertig für Version 1.1.2
GloExplorer; Datenbank-ID anzeigen.
ID: 20240917_3Typ: EXT
Benutzer/Rolle: GloExplorer-Benutzer
Beschreibung: Die Datenbank-ID soll zusätzlich zum Datenbanknamen angezeigt werden.
Nutzen: Da ab Version 1.1.2 die Referenzierung von Objekten datenbankübergreifend unterstützt wird, ist diese Angabe notwendig.
Status: Fertig für Version 1.1.2
GloDeveloper; bei Auswahl der Zugriffsmodalitäten (private, protected, public) kann der Wert überschrieben werden.
ID: 20240917_1Typ: ERR
Benutzer/Rolle: GloDeveloper-Benutzer
Beschreibung: Bei Auswahl der Zugriffsmodalitäten (privat, geschützt, öffentlich) kann der Wert in der Combobox überschrieben werden.
Lösung:
Status: Fehler behoben für Version 1.1.2
GlobalObjects-Objekte datenbankübergreifend referenzieren
ID: 20240727_2Typ: EXT
Benutzer/Rolle: Entwickelnde Benutzer von GlobalObjects
Beschreibung: Derzeit kann ein persistentes Objekt nur andere persistente Objekte aus derselben Datenbank referenzieren. Datenbankübergreifende Referenzen sollen umgesetzt werden. So soll es beispielsweise möglich sein, dass Objekte aus einer "Buchhaltungsdatenbank" Objekte aus einer "Adressdatenbank" referenzieren und umgekehrt.
Nutzen: Dadurch ist es möglich, eine Datenbank mit anderen Datenbanken zu verwenden, ohne Objekte redundant vorhalten zu müssen.
Akzeptanzkriterien: siehe oben
Status: Fertig für Version 1.1.2
GloDeveloper; persistente Objekte datenbankübergreifend einpflegen
ID: 20240727_3Typ: EXT
Benutzer/Rolle: Nutzer des GloDeveloper
Beschreibung: Derzeit kann im GloDeveloper ein persistentes Objekt nur andere persistente Objekte aus derselben Datenbank referenzieren. Datenbankübergreifende Referenzen sollen umgesetzt werden. So soll es beispielsweise möglich sein, dass Objekte aus einer "Buchhaltungsdatenbank" Objekte aus einer "Adressdatenbank" referenzieren und umgekehrt.
Nutzen: Dadurch ist es möglich, Objekte einer Datenbank Objekte aus einer anderen Datenbank referenzieren zu lassen und das Schema wie den entsprechenden Sourcecode generieren zu lassen.
Akzeptanzkriterien: siehe oben
Status: Fertig für Version 1.1.2
GloDeveloper; automatisches erzeugen einer eindeutigen Datenbank-ID
ID: 20240727_4Typ: EXT
Benutzer/Rolle: Nutzer des GloDeveloper
Beschreibung: Der GloDeveloper soll auromatisch eine eindeutige Datenbank-ID bei neuanlage vergeben.
Nutzen: Für den datenbankübergreifenden Zugriff auf Objekte, ist es unabdingbar, dass jede Datenbank eine eindeutige ID hat.
Akzeptanzkriterien: siehe oben
Status: Fertig für Version 1.1.2
GloExplorer; persistente Objekte datenbankübergreifend bearbeiten
ID: 20240727_4Typ: EXT
Benutzer/Rolle: Nutzer des GloExplorer
Beschreibung: Derzeit kann im GloExplorer ein persistentes Objekt nur andere persistente Objekte aus derselben Datenbank referenzieren. Datenbankübergreifende Referenzen sollen umgesetzt werden. So soll es beispielsweise möglich sein, dass Objekte aus einer "Buchhaltungsdatenbank" Objekte aus einer "Adressdatenbank" referenzieren und umgekehrt.
Nutzen: Dadurch ist es möglich, Objekte einer Datenbank Objekte aus einer anderen Datenbank referenzieren zu lassen.
Akzeptanzkriterien: siehe oben
Status: Fertig für Version 1.1.2
GlobalObjects; Hinzufügen der Transaktions-Methode int glo::Base::rollBackTransaction() .
ID: 20240905_1
Typ: EXT
Benutzer/Rolle: Entwickelnde Benutzer von GlobalObjects
Beschreibung: Eine Transaktion kann mit einem
int glo::Base::abortTransaction() abgebrochen werden, was bedeutet, dass alle Datenbankaktionen bis zum letzten int glo::Base::beginTransaction() verworfen werden. Dies ist dem "Wording" von "FastObjects" geschuldet. Um Entwicklern entgegenzukommen, die gerne von einem „Rollback“ sprechen möchten, wird die Methode int glo::Base::rollBackTransaction() eingeführt, die dasselbe tut wie die Methode int glo::Base::abortTransaction().
Vorteile: Ggf. einfacheres Lesen des Source-Codes.
Akzeptanzkriterien: Siehe oben
Status: Fertig für Version 1.1.2
GlobalObjects; GlobalObjects stürzt ab, wenn sich in der Datenbank Datumsfelder befinden, in denen sich "zu große" Zahlen befinden
ID: 20240903_1Typ: ERR
Nutzer/Rolle: Entwickelnde Benutzer von GlobalObjects
Beschreibung: Wenn aus irgendeinem Grund (32 versus 64 Bit?) zu große Zahlen in einem Datumsfeld befinden, stürzt GlobalObjects bei der Zuweisung eines solchen Datenfelds an ein glo::DateTimeRecordAttribute ab..
Lösung: std::localtime liefert bei Übergabe eines zu großen Wertes eine Zeiger (struct std::tm*) auf NULL_PTR und stürzt in Folge auf eine Zugriff auf diesen ab. Dieses wird jetzt abgefangen.
Status: Fehler behoben für Version 1.1.2
GlobalObjects; TOndemand liefert zwar bei erfolglosem Zugriff auf referenziertes Objekt einen Fehler, löscht aber einen ggf. vorhandene Zeiger aus übergebenen std::shared_ptr nicht.
ID: 20240903_2Typ: ERR
Nutzer/Rolle: Entwickelnde Benutzer von GlobalObjects
Beschreibung: Wenn die Referenz in einem TOndemand nicht aus der Datenbank geladen werden kann, wird eine vorhandene Referenz in der übergebenen Rückgabereferenz (Zeiger oder std::shared_ptr) nicht entfernt. Da nicht alle Entwickler den Fehlercode beim Ladeversuch auswerten, sondern nur die übergebene Rückgabereferenz prüfen (und erwarten, dass diese NULL_PTR ist, wenn das Laden aus der DB fehlgeschlagen ist), wird die übergebene Rückgabereferenz auf NULL_PTR gesetzt, wenn das Laden aus der DB erfolglos ist.
Lösung: s.o.
Status: Fehler behoben für Version 1.1.2
GlobalObjects; schnelleres Lesen und Speichern persistenter Objekte.
ID: 20240823_1Typ: EXT
Benutzer/Rolle: Entwickelnde Benutzer von GlobalObjects
Beschreibung: Derzeit ist das Lesen und Schreiben großer Objekte aus der Datenbank unverhältnismäßig langsam. Dies liegt unter anderem daran, dass der Kern von GlobalObjects ursprünglich ohne Indizes implementiert wurde und diese in einigen Funktionen nicht verwendet werden.
GlobalObjects wird überarbeitet, sodass die Kernfunktionen wie Lesen und Speichern an die Verwendung des Objekt-ID-Index angepasst werden.
Vorteile: Schnellerer Zugriff auf die Datenbank
Akzeptanzkriterien: Siehe oben
Status: Erste Performanceoptimierungen umgesetzt. Das Lesen aus der Datenbank konnte um den Faktor 14 beschleunigt werden, das Schreiben um den Faktor 3.
GloExplorer; bleibt manchmal nach dem Beenden im Speicher
ID: 20240819_1Typ: ERR
Nutzer/Rolle: Nutzer des GloExplorer
Beschreibung: Wenn der GloExplorer mit zwei geöffneten Datenbanken geschlossen wird, beendet sich dieser nicht immer vollständig. Bisweilen kann eine zuvor lokal geöffnete Datenbank nicht mehr geöffnet werden, weile diese vom im Hintergrund laufenden "Instanz" von etwas aus dem GloExplorer noch geöffnet ist. Der GloExplorer-Prozess kann dann nur noch im Task-Manager abgeschossen werden.
Problemumgehung: Vor dem Beenden des GloExplorer alle Fenster und Datenbanken schließen.
Status: Fehler behoben für Version 1.1.2
GlobalObjects Version 1.1.1
GlobalObjects: In der Hoffnung auf eine Leistungsverbesserung wurden einige Änderungen an glo::Record vorgenommen.
ID: 20240727_1Typ: EXT
Benutzer/Rolle: Entwickelnde Benutzer von GlobalObjects
Beschreibung: Beim Speichern werden alle Attribute durchlaufen, um eventuell abhängige Objekte zu speichern.
Lösung: Die entsprechenden Referenzattribute werden nun in einem separaten Vektor gespeichert.
Status: Fertig für Version 1.1.1
GlobalObjects Version 1.1.0
GlobalObjects: In der Methode glo::BasePersistent::activate() kann kein Datenbankzugriff erfolgen; die Anwendung stürzt ab.
ID: 20240719_1Typ: ERR
Benutzer/Rolle: Entwickelnde Benutzer von GlobalObjects
Beschreibung: siehe oben
Lösung:
Status: Fehler behoben für Version 1.1.0
GlobalObjects; Transaktionen und Sperren an einzelne Threads binden.
ID: 20240709_1Typ: EXT
Nutzer/Rolle: Entwickelnde Nutzer von GlobalObjects
Beschreibung: Momentan sind Sperre und Transaktion an die aufrufende Instanz gebunden. Das heißt, die Instanz, die die Datenbank geöffnet hat, kann eine Sperre und/oder Transaktion initiieren. Das funktioniert hervorragend, wenn die Anwendung im Single-Thread-Modus arbeitet. Sollen mehrere Threads im Multi-Thread-Modus auf die Datenbanken zugreifen, kommt es zu Problemen, wenn einzelne Threads Objekte sperren oder eine Transaktion initiieren wollen. GlobalObjects kann aktuell nicht sicherstellen, dass ein von einem Thread gesperrtes Objekt auch für andere Threads gesperrt ist. Noch schwieriger wird es, wenn es um die Transaktionskontrolle geht. Dadurch würden verschachtelte Transaktionen entstehen und das Ergebnis ist unvorhersehbar.
GlobalObjects wird dahingehend erweitert, dass Sperren und Transaktionen generell für den einzelnen Thread gelten. Das ist eine sinnvolle Erweiterung, um im Multi-Thread-Modus arbeiten zu können und es gibt im Single-Thread-Modus keine Einschränkungen.
Nutzen: s.o.
Akzeptanzkriterien: s.o.
Status: Fertig für Version 1.1.0
glo::TAllSet; wenn nur ein Objekt im AllSet voprhanden ist, scheitert Methode ::get(...) mit Parameter glo::END.
ID: 20240703_1Typ: ERR
Nutzer/Rolle: Entwickelnde Nutzer von GlobalObjects
Beschreibung: Hat ein AllSet nur ein Element und es wird eine get-Methode mit dem glo::EnSeekMode -> glo::END aufgerufen, wird kein Element mit der Fehlermeldung ERR_RANGE = -13032 gefunden.
Lösung:
Status: Fehler behoben für Version 1.1.0
GlobalObjects Version 1.0.10
Eine Menge von Objekten in einer Anweisung löschen
ID: 20240624_1Typ: EXT
Nutzer/Rolle: Entwickelnde Nutzer von GlobalObjects
Anforderung: Es soll ermöglicht werden, Objekt deren Objekt-IDs in einer Liste, einem Set oder einem Vector sind, in einer Anweisung zu löschen. Es werden entweder alle Objekte mit den entsprechenden Objekt-IDs gelöscht, oder keines (z.B. wenn Objekt(e)gesperrt).
Nutzen: Vereinfachtes Löschen von einer Menge von Objekten.
Akzeptanzkriterien: s.o.
Status: Fertig für Version 1.0.10
GloDeveloper; Schlüsselworte 'persistent' 'transient' mit Text einrahmen
ID: 20240617_1Typ: EXT
Nutzer/Rolle: Entwickelnder Nutzer von GlobalObjects und einem Doikumentations-Tools
Anforderung: GlobalObjects verwendet in den generierten Header-Dateien die Schlüsselwörter 'persistent' und 'transient', um den Bereich der persistenten Attribute abzugrenzen.
Nicht alle Dokumentationstools, wie beispielsweise Doxygen, können damit umgehen. Die folgenden transienten Attribute werden nicht korrekt erkannt. Um dies zu vermeiden, können vor und nach den Schlüsselwörtern 'persistent' und 'transient' zusätzliche Anweisungen hinzugefügt werden.
Dieses kann in den "Programmeinstellungen/Verschiedenes/Schlüsselworte 'persistent' und 'transient' einfassen" des GloDevelopers vorgenommen werden.
Nutzen: Die Nutzung von z.B. Doxygen wird verbessert.
Akzeptanzkriterien: s.o.
Status: Fertig für Version 1.0.10
GlobalObjects Version 1.0.9
Indiziertes Objekt aus AllSet holen ist fehlerhaft, wenn der Index als Parameter übergeben wird
ID: 20240603_1Typ: ERR
Nutzer/Rolle: Entwickelnder Nutzer von GlobalObjects
Beschreibung: Im AllSet wurde bei Übergabe eines Indexnamens in div. Holfunktionen der Index nicht gefunden.
Lösung: Es wurde der Name des Indexes nicht richtig aufgelöst, wenn er als voller Name übergeben wurde.
Status: Fehler behoben für Version 1.0.9
Lock für referenzierte Objekte erneuern
ID: 20240202_1Typ: EXT
Nutzer/Rolle: Nutzer von GlobalObjects
Anforderung: Bei einem Sperren von Objekten kann ein Tiefenmodus mitgegeben werden, welcher angibt, ob und welche referenzierten Objekte mitgesperrt werden sollen. Wenn ein referenziertes Objekt mitgesperrt wird, wird bei einem Austausch des referenzierten Objekte das jetzt nicht mehr referenzierte Objekte nicht automatisch freigegeben wie auch das neu referenzierte Objekt nicht automatisch mitgesperrt. Es wird eine Methode relock(...) eingeführt, die mit den Parametern einer vorhandenen Sperre aufgerufen werden kann. Diese Methode führt ein unlock(...) und anschließendes lock(...) eines schon gesperrten Objekts aus, womit neu referenzierte Objekte je nach Sperrmodus, wenn möglich, mitgesperrt werden und vorherige mitgesperrte referenzierte Objekte freigegeben werden. Wenn neu referenzierte Objekte nicht gesperrt werden können, wird der vorherige Sperrzustand beibehalten.
Nutzen: Eine einfache Methodik, um referenzierte Objekte mit sperren zu können.
Akzeptanzkriterien: S.o.
Status: Fertig für Version 1.0.9
GlobalObjects; Es sollen eine Objekt-ID von allen Einzelreferenzen als Index zulässig sein
ID: 20240522_1Typ: EXT
Nutzer/Rolle: Nutzer von GlobalObjects
Anforderung: Bislang konnte bei einer Einzelreferenz nur ein Attribut als Index genutzt werden. Zudem musste die Referenz "dependent" sein. Sollte eine Objekt-ID einer Referenz als Index genutzt werden, konnte das nicht über einen Zeiger geschehen, sondern es musste eine glo::ObjID als Attribut vorhanden sein. Es soll dem Nutzer des GloDeveloper ermöglicht werden, die Objekt-ID einer Referenz als Index zu nutzen.
Nutzen: Damit wird es möglich, die Objekt-ID eines einzelnen referenzierten Objekts als Index zu nutzen..
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn die genannte Index-Auswahl im GloDeveloper ermöglicht wird.
Status: Fertig für 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
Nutzen: Damit wird es möglich, std::unique_ptr
Akzeptanzkriterien: Die Anforderung ist erfüllt, wenn persisterne Klassen std::unique_ptr
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_1Typ: 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_1Typ: 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_1Typ: 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.
Status: Fehler behoben für Version 1.0.8
GlobalObjects; In Transaktion erstmalig gespeicherte Objekte können nicht überwacht werden.
ID: 20240214_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_2Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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
in
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_1Typ: 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_1Typ: 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_2Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_2Typ: 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_1Typ: 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_2Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: ERR
Nutzer/Rolle: Nutzer von GlobalObjects
Beschreibung: Wenn ein persistentes Objekt ein glo::TOndemand
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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_2Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_3Typ: 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_6Typ: 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_1Typ: 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_2Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_4Typ: 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_1Typ: 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_1Typ: 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_1Typ: 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_2Typ: 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_3Typ: 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_4Typ: 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