GlobalObjects 'Product Backlog' completed
Fixed errors and enhancements are displayed on this page, along with the version in which they were incorporated.
GlobalObjects Version 1.1.3
GloDeveloper; Prevent multiple inclusion.
ID: 20241119_1Type: ERR
User/Role: GloDeveloper user
Description: When generating the header files, it is not checked whether a used class is included multiple times (as a superclass and as a referenced class).
Solution:
Status: Bug fixed for version 1.1.3
GlobalObjects; table is destroyed if, for example, a string attribute is saved in a file and the ObjID is longer than 10 characters
ID: 20241126_1Type: ERR
User/Role: Developing users of GlobalObjects
Description: If an attribute of type String, EuBlob or a list of ObjIDs is saved, the data is saved in a file (only in special cases for strings). The file name can only be 10 characters long. The object ID of the respective object with the attribute is used. However, this can now be larger, consisting of 3 unsigned longs. The generated file name is now written to the table, too long, which destroys it.
Solution: The object counter of the object ID is used.
Status: Bug fixed for version 1.1.3
Locking followed by refresh
ID: 20241123_1Type: EXT
User/Role: User of GlobalObjects
Requirement: A method should be provided that initiates a refresh directly when an object is locked.
Benefit: A lock and a refresh are two tasks that are sent individually to the GloManager. Combining both tasks into one task will increase speed.
Acceptance criteria: The requirement is met when a lock and a refresh are carried out in one action.
Status: Ready for version 1.1.3
GlobalObjects Version 1.1.2
GloExplorer; Display a new editing window in the middle of the MDI.
ID: 20240917_4Type: EXT
User/Role: GloExplorer user
Description: Currently, an object editing window is displayed somewhere and then often has to be dragged into the workspace.
Use: Reduce a little inconvenience.
Solution: With reasonable effort, at least a new editing window could be positioned near the mouse pointer.
Status: Ready for version 1.1.2
GloExplorer; Display database ID.
ID: 20240917_3Type: EXT
User/Role: GloExplorer user
Description: The database ID should be displayed in addition to the database name.
Benefit: Since referencing of objects is supported across databases from version 1.1.2 onwards, this information is necessary.
Status: Ready for version 1.1.2
GloDeveloper; when selecting access modalities (private, protected, public) the value can be overwritten.
ID: 20240917_1Type: ERR
User/Role: GloDeveloper user
Description: When selecting access modalities (private, protected, public) the value in the combo box can be overwritten.
Solution:
Status: Bug fixed for version 1.1.2
Reference GlobalObjects objects across databases
ID: 20240727_2Type: EXT
User/Role: Developing users of GlobalObjects
Description: At present, a persistent object can only reference other persistent objects from the same database. References across databases should be implemented. For example, it should be possible for objects from an "accounting database" to reference objects from an "address database" and vice versa.
Benefit: This makes it possible to use a database with other databases without having to keep objects redundant.
Acceptance criteria: see above
Status: Ready for version 1.1.2
GloDeveloper; maintain persistent objects across databases
ID: 20240727_3Type: EXT
User/Role: GloDeveloper user
Description: Currently, in GloDeveloper, a persistent object can only reference other persistent objects from the same database. Cross-database references are to be implemented. For example, it should be possible for objects from an "accounting database" to reference objects from an "address database" and vice versa.
Benefit: This makes it possible for objects from one database to reference objects from another database and for the schema to be generated like the corresponding source code.
Acceptance criteria: see above
Status: Ready for version 1.1.2
GloDeveloper; automatically generate a unique database ID
ID: 20240727_4Type: EXT
User/Role: GloDeveloper user
Description: The GloDeveloper should automatically assign a unique database ID when a new database is created.
Benefit: For cross-database access to objects, it is essential that each database has a unique ID.
Acceptance criteria: see above
Status: Ready for version 1.1.2
GloExplorer; edit persistent objects across databases
ID: 20240727_4Type: EXT
User/Role: GloExplorer user
Description: Currently, in GloExplorer, a persistent object can only reference other persistent objects from the same database. Cross-database references are to be implemented. For example, it should be possible for objects from an "accounting database" to reference objects from an "address database" and vice versa.
Benefit: This makes it possible for objects from one database to reference objects from another database.
Acceptance criteria: see above
Status: Ready for version 1.1.2
GlobalObjects; Add transaction method int glo::Base::rollBackTransaction()
.
ID: 20240905_1
Type: EXT
User/Role: GlobalObjects developing users
Description: A transaction can be aborted with a
int glo::Base::abortTransaction()
, which means that all database actions up to the last int glo::Base::beginTransaction()
are discarded. This is due to the "wording" of "FastObjects". To accommodate developers who would like to talk about a "rollback", the method int glo::Base::rollBackTransaction()
is introduced, which does the same thing as the method int glo::Base::abortTransaction()
.
Advantages: Easier to read the source code if necessary.
Acceptance criteria: See above
Status: Ready for version 1.1.2
GlobalObjects; GlobalObjects crashes if there are date fields in the database that contain "too large" numbers
ID: 20240903_1Type: ERR
User/Role: GlobalObjects development users
Description: If for some reason (32 versus 64 bit?) there are too large numbers in a date field, GlobalObjects crashes when the assignment of such a data field to a glo::DateTimeRecordAttribute..
Solution: std::localtime returns a pointer (struct std::tm*) to NULL_PTR when passing a value that is too large and crashes as a result of accessing it. This is now intercepted.
Status: Bug fixed for version 1.1.2
GlobalObjects; TOndemand returns an error if access to the referenced object is unsuccessful, but does not delete any existing pointer from the passed std::shared_ptr.
ID: 20240903_2Type: ERR
User/Role: Developing users of GlobalObjects
Description: If the reference in a TOndemand cannot be loaded from the database, any existing reference in the passed return reference (pointer or std::shared_ptr) is not removed. Since not all developers evaluate the error code when attempting to load, but only check the passed return reference (expecting that this is NULL_PTR if loading from the DB has failed), the passed return reference is set to NULL_PTR if loading from the DB is unsuccessful.
Solution: see above
Status: Error fixed for version 1.1.2
GlobalObjects; speed up reading and saving of persistent objects.
ID: 20240823_1Type: EXT
User/Role: Developing users of GlobalObjects
Description: Currently, reading and writing large objects from the database is disproportionately slow. This is due, among other things, to the fact that the core of GlobalObjects was originally implemented without indexes and in some functions they are not used.
GlobalObjects is being revised so that the core functions such as reading and saving are adapted to the use of the object ID index.
Benefits: Faster access to the database
Acceptance criteria: see above
Status: First performance optimizations implemented. Reading from the database could be accelerated by a factor of 14, writing could be accelerated by a factor of 3.
GloExplorer; sometimes remains in memory after closing
ID: 20240819_1Type: ERR
User/Role: GloExplorer user
Description: If GloExplorer is closed with two databases open, it does not always close completely. Sometimes a database that was previously opened locally can no longer be opened because it is still open by an "instance" of something from GloExplorer running in the background. The GloExplorer process can then only be killed in the Task Manager.
Workaround: Close all windows and databases before closing GloExplorer.
Status: Bug fixed for version 1.1.2
GlobalObjects Version 1.1.1
GlobalObjects: in the hope of improving performance, some changes were made to glo::Record.
ID: 20240727_1Type: EXT
User/Role: Developing users of GlobalObjects
Description: When saving, all attributes are iterated through in order to save any dependent objects.
Solution: The corresponding reference attributes are now kept in a separate vector.
Status: Ready for version 1.1.1
GlobalObjects Version 1.1.0
GlobalObjects: In the method glo::BasePersistent::activate() no database access can be made; the application crashes.
ID: 20240719_1Type: ERR
User/Role: Developing users of GlobalObjects
Description: see above
Solution:
Status: Bug fixed for version 1.1.0
GlobalObjects; Link transactions and locks to individual threads.
ID: 20240709_1Type: EXT
User/Role: Developing users of GlobalObjects
Requirement: At the moment, a lock and transaction are tied to the calling instance. This means that the instance that opened the database can initiate a lock and/or transaction. This works excellently when the application is working in single-thread mode. If several threads are to access the databases in multi-thread mode, problems arise when individual threads want to lock objects or initiate a transaction. GlobalObjects cannot currently ensure that an object locked by one thread is locked for other threads. It is even more difficult when it comes to transaction control. This would result in nested transactions and the result is unpredictable.
GlobalObjects will be extended to the extent that locks and transactions generally apply to the individual thread. This is a useful extension to be able to work in multi-thread mode and there are no restrictions in single-thread mode.
Benefit: see above
Acceptance criteria: see above
Status: Ready for version 1.1.0
glo::TAllSet; if there is only one object in the AllSet, method ::get(...) with parameter glo::END fails.
ID: 20240703_1Type: ERR
User/Role: Developing users of GlobalObjects
Description: If an AllSet has only one element and a get method with the glo::EnSeekMode -> glo::END is called, no element is found with the error message ERR_RANGE = -13032.
Solution:
Status: Bug fixed for version 1.1.0
GlobalObjects Version 1.0.10
Delete a set of objects in one statement
ID: 20240624_1Type: EXT
User/Role: Developing users of GlobalObjects
Requirement: It should be possible to delete objects whose object IDs are in a list, a set or a vector in one statement. Either all objects with the corresponding object IDs are deleted, or none (e.g. if object(s) are locked).
Benefit: Simplified deletion of a set of objects.
Acceptance criteria: see above
Status: Ready for version 1.0.10
GloDeveloper; enclose keywords 'persistent' 'transient' with text
ID: 20240617_1Type: EXT
User/Role: Developing user of GlobalObjects and a documentation tool
Requirement: GlobalObjects uses the keywords 'persistent' and 'transient' in the generated header files to delimit the scope of the persistent attributes.
Not all documentation tools, such as Doxygen, can handle this. The following transient attributes are not recognized correctly. To avoid this, additional instructions can be added before and after the keywords 'persistent' and 'transient'.
This can be done in the "Program settings/Miscellaneous/Include keywords 'persistent' and 'transient'" of the GloDeveloper.
Benefit: The use of e.g. Doxygen is improved.
Acceptance criteria: see above
Status: Ready for version 1.0.10
GlobalObjects Version 1.0.9
Getting an indexed object from AllSet is incorrect if the index is passed as a parameter.
ID: 20240603_1Type: ERR
User/Role: Developing user of GlobalObjects
Description: In AllSet, the index was not found when an index name was passed in various fetch functions.
Solution: The name of the index was not resolved correctly if it was passed as a full name.
Status: Bug fixed for version 1.0.9
Renew lock for referenced objects
ID: 20240202_1Type: EXT
User/Role: User of GlobalObjects
Requirement: When locking objects, a depth mode can be specified, which specifies whether and which referenced objects should also be locked. If a referenced object is also locked, when the referenced object is replaced, the object that is no longer referenced will not be automatically released and the newly referenced object will not be automatically locked. A method relock(...) is introduced that can be called with the parameters of an existing lock. This method executes an unlock(...) and then a lock(...), which locks newly referenced objects, if possible, and releases previously locked referenced objects. If newly referenced objects cannot be locked, the previous locked state is retained.
Benefit: A simple methodology for locking referenced objects.
Acceptance criteria: S.o.
Status: Ready for version 1.0.9
GlobalObjects; an object ID of all individual references should be permitted as an index
ID: 20240522_1Type: EXT
User/Role: User of GlobalObjects
Requirement: Until now, only one attribute could be used as an index for a single reference. In addition, the reference had to be “dependent”. If an object ID of a reference was to be used as an index, this could not be done via a pointer, but a glo::ObjID had to be present as an attribute. The GloDeveloper user should be able to use the object ID of a reference as an index.
Benefit: This makes it possible to use the object ID of a single referenced object as an index.
Acceptance criteria: The requirement is met if the above-mentioned index selection is enabled in GloDeveloper.
Status: Ready for version 1.0.9
GlobalObjects; The std::unique_ptr should be made possible as a persistent attribute of persistent classes
ID: 20240304_1
Type: EXT
User/Role: User of GlobalObjects
Requirement: So far only the std::shared_ptr
Benefit: This makes it possible to process std::unique_ptr
Acceptance criteria: The requirement is met if persistent classes can use std::unique_ptr
Status: Ready for version 1.0.9
GlobalObjects version 1.0.8
GloExplorer, GloDeveloper; no external editor can be called under Linux
ID: 20240208_1Type: ERR
User/Role: User of GloExplorer and GloExplorer
Description: An external editor can be entered in the settings in both programs, which can be called up as an alternative to entering text in the text field, for example. This worked on Windows but not on Linux.
Solution: The call to QProcess with the call of the respective editor in the EuQtExternPlainTextEditor class has been adjusted. Originally the QProcess was created on the stack and "died" too quickly under Linux. Now the QProcess is managed as a member of EuQtExternPlainTextEditor.
Status: Bug fixed for version 1.0.8
GloExplorer; Notify colors set are not applied for "Insert" and "DeleteInBase"
ID: 20220514_1Type: ERR
User/Role: User of GloExplorer
Description: Color settings for various notifications can be set in the settings. If objects are added to the AllSet or deleted from the AllSet, the entries are not taken into account.
Solution: When "Resetting" the color marking is now carried out until the object is displayed in the AllSet representation and when "Deleting" the color marking is carried out before it is removed from the AllSet representation .
Status: Bug fixed for version 1.0.8
GloDeveloper; Settings does not save text preferences in UTF-8
ID: 20200704_1Type: ERR
User/Role: GloDeveloper user
Description: If template texts are entered in the program settings in GloDeveloper, umlauts etc. are not saved in UTF-8 in the GloDeveloper.ini.
Status: Bug fixed for version 1.0.8
GlobalObjects; Objects saved for the first time in a transaction cannot be monitored.
ID: 20240214_1Type: ERR
User/Role: User of GlobalObjects
Description: Since the glo::LockManager can only monitor objects that are stored in tables in the database, objects that are only in the transaction memory are not taken into account. A monitoring attempt is acknowledged with an error.
Solution: When determining the objects to be monitored, the objects from the transaction memory are taken into account first and then the objects from the tables.
Status: Bug fixed for version 1.0.8
GlobalObjects; Objects saved for the first time in a transaction cannot be locked.
ID: 20240212_1Type: ERR
User/Role: User of GlobalObjects
Description: Since the glo::LockManager can only lock objects that are stored in tables in the database, objects that are only in transaction memory are not taken into account. A lock attempt is acknowledged with an error.
Solution: When determining the objects to be locked, the objects from the transaction memory are taken into account first and then the objects from the tables.
Status: Bug fixed for version 1.0.8
GloDeveloper; When new tables are created, the files in the directories for external data are not deleted.
ID: 20240204_1Type: ERR
User/Role: User of GloDeveloper
Description: When the tables are created by GloDeveloper, the directories for external data are created if they do not exist. To date, existing external data from old table entries has not been deleted. But this is required.
Solution: If directories exist, all existing files will be deleted when a new table is created.
Status: Bug fixed for version 1.0.8
GlobalObjects; A new object can be saved in a transaction, but cannot be deleted in that transaction before a commit.
ID: 20240124_1Type: ERR
User/Role: User of GlobalObjects
Description: When a new object is saved for the first time in a transaction, it cannot be deleted in the transaction with ::deleteInBase() before it ends.
Solution: The record to be deleted, for example with attributes of the type std:.string, may not yet have a file name set in which the string is saved. The equivalent record is read from the table before deletion and could then be deleted with its referenced files. However, records to be saved in a transaction are now left in the transaction memory until a commit or abortion occurs. Of course, deleting a new record that is not yet in the table fails because reading the equivalent record fails.
The file names to be determined, e.g. of the string files, are now determined without reading a record from the table. It became the method for this
void Record::setDeterminedFileNamesForAllAttributesWithThese()
written, which sets the necessary file names in the respective attributes.Status: Bug fixed for version 1.0.8
GloExplorer; After creating a new object, no lock and watch can be set
ID: 20240123_1Type: ERR
User/Role: User of GloExplorer
Description: When a new object is created, no lock and watch can be set, that's ok. But when saved, selections should be released.
Solution: After saving, the corresponding widgets were activated.
Status: Bug fixed for version 1.0.8
GloServer: The GloServer crashes when a client has an observation for the locking and the locking client crashes
ID: 20240102_1Type: ERR
User/Role: User of GlobalObjects
Description: If a client "A" of a GloServer has set an observation, for example, to release a lock and this object is locked by another client "B" and then this locking client "B" crashes, the crashed client was accessed (to provide its name and ID) when creating the auto-release notification; and he was already dead ;-).
Solution: The error was fixed by having an OrderMsg copy the name and ID from the client (communicator). Only this copied data will be accessed, even if the client has already died.
Status: Ready for version 1.0.8
GloExplorer: AllSet does not recognize inherited indexes
ID: 20231218_1Type: ERR
User/Role: GloExplorer user
Description: If an AllSet with an index is opened, a corresponding button is displayed with which an AllSet is sorted and opened for query via this index.
This doesn't work with inherited indexes.
Solution: The error has been fixed. There were various reasons for this in GlobalObjects as well as in GloExplorer.
Status: Ready for version 1.0.8
GlobalObjects version 1.0.7
GloDeveloper: Mark class as library class
ID: 20190722_2Type: EXT
User/Role: GloDeveloper user
Requirement: It should be possible to mark a class as a library class with GloDeveloper. No header and source files should then be generated for these.
Benefit: Reuse is supported.
Acceptance criteria: The requirement is met if the developing user can specify for each persistent class whether header and source files are generated for them. It is achieved by simply not entering a file name, which was not possible before.
Status: Ready for version 1.0.7
GloDeveloper: Memory leak
ID: 20200419_1Type: ERR
User/Role: GloDeveloper user
Description: When a Base is removed from a project in GloDeveloper, the ProjectBase type object remains in memory.
Solution: In int GloQtDeveloperProject::removeBaseProject( ProjectBase * pRemoveBaseProject ) pRemoveBaseProject was removed from the project list, but not from memory.
This has now been implemented.
Status: Bug fixed for version 1.0.7
GloDeveloper: Allow classes without filenames
ID: 20231213_1Type: EXT
User/Role: GloDeveloper user
Requirement: Previously, persistent classes could not be processed without filenames. This should be ensured and these classes should be recognizable in the developer with a different icon.
Benefit: So that persistent classes from another database can be reused, it makes sense not to have the header- and source files generated again.
Acceptance criteria: The requirement is met when persistent classes without file names are generated and processed.
Status: Ready for version 1.0.7
GloDeveloper: copying a class with subclasses only copies first subclass level
ID: 20210210_1Type: ERR
User/Role: GloDeveloper user
Description: If a class with subclasses, which in turn have subclasses, is to be copied in the GloDeveloper, only the direct subclasses and not the entire branch are copied.
Solution: In the recursion, the information that "deep" copying should be carried out was not passed; is fixed.
Status: Bug fixed for version 1.0.7
GloDeveloper: Drag & drop of attributes in a class makes moving attributes disappear
ID: 20231207_1Type: ERR
User/Role: GloDeveloper user
Description: If attributes are moved in a class using drag & drop in GloDeveloper, they disappear.
Solution:
connect ( m_pTreeWidget_Attributes, SIGNAL( signal_ObjectDraged( QList
in
void GloQtDeveloperClassProp::init()
was implemented twice. This means that it is called twice and the information that was moved in the same TreeView is lost.Status: Bug fixed for version 1.0.7
GlobalObjects version 1.0.6
GlobalObjects; cannot save string index with limited number of characters
ID: 20231108_1Type: ERR
User/Role: User of GlobalObjects
Description: Objects with a limited-length string attribute used as an index cannot be saved if the allowed string length matches the set index string length.
Solution:
std::string StringRecordAttribute::getValueAsString( const std::string & rsValue, bool bFillBlanks ) const
fixed.Status: Bug fixed for version 1.0.6
GlobalObjects version 1.0.5
GlobalObjects; persistent classes with namespace
ID: 20230223_1Type: EXT
User/Role: User of GlobalObjects
Requirement: Currently, persistent classes cannot be assigned to a namespace. GlobalObjects with the tools is intended to generate and process persistent classes in a namespace.
Benefit: This makes it possible to process classes with the same name in different namespaces with GlobalObjects.
Acceptance criteria: The requirement is met when persistent classes are generated and processed in namespaces.
Status: Ready for version 1.0.5
GloDeveloper; Language setting for the index is not adopted
ID: 20230223_2Type: ERR
User/Role: GloDeveloper user
Description: If the language setting is selected for an index, it is not adopted.
Solution: The language selection dialog was initialized with "Qt::WA_DeleteOnClose". As a result, the dialog data was no longer available. The language selection dialog is now removed from memory after the data query.
Status: Ready for version 1.0.5
GlobalObjects; An incorrect object assignment to a database is not recognized
ID: 20230106_1Type: ERR
User/Role: User of GlobalObjects
Description: If two different objects are stored in different databases, they may each have the same class ID.
Registering an object that does not exist as a type in a DB is therefore incorrect because only the class ID is checked. An exception is only thrown when saving.
Solution: The class type in PrivateBase::assignObject(...) is checked and if the type is incorrect, a corresponding error (glo::ERR_WRONG_BASE) is returned.
Status: Ready for version 1.0.5
GlobalObjects version 1.0.4
Initiate Notify for "Save" without actually saving
ID: 20220622_1Type: EXT
User/Role: User of GlobalObjects
Requirement: It should be possible to initiate a "WNM_WRITE" notification for a persistent object without having to save the object in question.
If an object 'A' directly references another object, when a reference changes, the referencing object 'A' must be saved; this initiates a notification to observing instances that object 'A' has changed.
However, if object 'A' references another object via an association class object, only the association class object needs to be saved when the reference changes. So that the observing instances of object 'A' are informed about the reference change, a notification that object 'A' has changed should be initiated when saving the association class object, without having to save object 'A'.
Benefit: Unnecessary saving just to initiate a notification is avoided.
Acceptance criteria: The requirement is met if a "WNM_WRITE" notification can be triggered without actually saving.
Status: Ready for version 1.0.4
GlobalObjects version 1.0.3
GloExplorer, unspecific behavior when the connection to a GloServer is lost
ID: 202202029_1Type: ERR
User/Role: GloExplorer user
Description: If the GloExplorer opened a database via the GloServer, the behavior of the GloExplorer was undefined when the connection to the GloServer was lost. Every now and then there would be a crash due to access to a NULL pointer.
Solution: EXT 20220307_1 implemented and installed in the GloExplorer.
Status: Ready for version 1.0.3
Processing a connection loss to a GloServer
ID: 20220307_1Type: EXT
User/Role: User of GlobalObjects
Requirement: Previously, a loss of connection between GlobalObjects clients and a GloServer was only detected if the client evaluated the corresponding error message when accessing the server. However, it should be possible to be informed about a connection loss.
This is implemented via the “Observe/notify persistent objects” mechanism.
Benefit: It can react immediately to a client/server connection breakdown.
Acceptance criteria: S.o.
Status: Ready for version 1.0.3
GlobalObjects version 1.0.2
GloDeveloper and GloExplorer; Switching to Qt 6
ID: 20210126_1Type: EXT
User/Role: User of GloDeveloper and GloExplorer
Requirement: The Gui is ported to Qt 6.
Benefit: Adaptation to new developments
Acceptance criteria: The requirement is met if the GUI of GloDeveloper and GloExplorer is ported to Qt 6.
Status: Ready for version 1.0.2
GloDeveloper, memory leak when saving project
ID: 20211209_2Type: ERR
User/Role: GloDeveloper user
Description: When the project is saved, there is a memory leak.
Solution: In method int GloQtDeveloperProject::store() the created project file is removed from memory again.
Status: Ready for version 1.0.2
GloDeveloper, class selection display always shows class icon for "is open"
ID: 20211209_1Type: ERR
User/Role: GloDeveloper user
Description: The is open icon is always displayed in the tree view for selecting superclasses, even if there was nothing to open.
Solution: In method void EuQtMoTreeWidgetItem::expandBranch() the call setExpanded(true) is only made if there is something to expand.
Status: Ready for version 1.0.2
GlobalObjects version 1.0.1
GlobalObjects, switching from time_t to std::time_t
ID: 20211102_2Type: EXT
User/Role: User of GlobalObjects
Requirement: Changeing from time_t type to std::time_t.
Benefit: By switching from time_t to std::time_t, better continuity is achieved.
Acceptance criteria: The requirement is met if all GlobalObjects modules are switched to std::time_t.
Attention: In all schema files (*.ini), all entries "Type=time_t" must be changed to "Type=std::time_t", so that they can be read without errors.
Status: Ready for version 1.0.1
A generated class derived from glo::ObjCreator can only be included once with #include.
ID: 20211202_1Type: ERR
User/Role: GloDeveloper user
Description: When a class derived from glo::ObjCreator is generated, the keyword 'inline' is missing before the constructor and destructor. This means that the header file can only be integrated once.
Solution: Adjusted the file generation in BaseMaker::generateObjCreator(...).
Status: Bug fixed for version 1.0.1
GloDeveloper crashes when the glo::Persistent is to be edited
ID: 20211130_1Type: ERR
User/Role: GloDeveloper user
Description: If glo::Persistent is to be edited, GloDeveloper crashes.
Solution: The query as to whether the object to be edited is of type glo::Persistent (which has editing restrictions and therefore no toolbar for new attributes, for example) was incorrectly commented out (why knows why). Query activated again.
Status: Bug fixed for version 1.0.1
GlobalObjects, switching the spy classes from std::map to std::unordered_map
ID: 20211126_1Type: EXT
User/Role: User of GlobalObjects
Requirement: Switching the classes glo::CallBackSpy, glo::PersObjectSpy and glo::GenPersObjectSpy from std::map to std::unordered_map.
Benefit: A performance gain is expected by switching from std::map to std::unordered_map.
Acceptance criteria: The requirement is met if GlobalObject runs a little faster after the change without errors.
Status: Ready for version 1.0.1
GlobalObjects version 1.0.0
Enableing the context menu in GloDeveloper and GloExplorer using [Ctrl]+[F10]
ID: 20210910_1Type: EXT
User/Role: User of GloDeveloper and GloExplorer
Requirement: In TreeView displays, the context menu cannot be opened with the usual keyboard shortcut [Ctrl]+[F10].
Benefit: Users who like to work with the keyboard should be able to call up the context menu with the usual key combination [Ctrl]+[F10].
Acceptance criteria: The requirement is met if all TreeViews can make a context menu call using the key combination [Ctrl]+[F10].
Status: Ready for version 1.0.0
If object is saved, it cannot be deleted immediately
ID: 20210906_1Type: ERR
User/Role: User of GlobalObjects
Description: When an object is saved, it cannot be deleted immediately because the file positions of the ObjIDs in the m_TableObjIDMap are not set in the record. Only after a refresh()!
Solution: After saving a data record, the file position is transferred to the result record.
Status: Bug fixed for version 1.0.0
GlobalObjects: Automatic call of overridable methods before and after a Persistent::refresh(), Persistent::lock(), Persistent::unlock(), Persistent::setWatch(...), Persistent::unsetWatch( ...)
ID: 20210903_1Type: EXT
User/Role: User of GlobalObjects
Requirement: An overridable method should be able to be called before and after re-reading an object, locking or releasing and monitoring. It should be possible to transfer data from the method called first to the method called second.
Use: To avoid using the methods glo::BasePersistent::refresh(), glo::BasePersistent::lock(), glo::BasePersistent::unlock(), glo::BasePersistent::setWatch (...) and glo::BasePersistent::unsetWatch(...), they call an overridable method before and after their action, which the user of GlobalObjects can overwrite.
Any necessary additional actions can be initiated there.
Acceptance criteria: The requirement is met if the overridable Pre and post methods are called.
Status: Ready for version 1.0.0
GlobalObjects version 0.2.1 (2021.08.19 07:13)
GlobalObjects: TOndemand does not reference a database for a new object.
ID: 202108917_1Type: ERR
User/Role: User of GlobalObjects
Description: If a persistent object has a glo::TOndemand
Solution: A method postAssign(glo::Base & rBase) was introduced in which this is set for all references that need to know the database.
When assign(glo::Base & rBase) is called, postAssign(glo::Base & rBase) is called automatically.
Status: Bug fixed for version 0.2.1 (2021.06.15 16:20)
GlobalObjects version 0.2.0 (2021.08.10 14:45)
GloExplorer: Cannot save object with multiple references.
ID: 20210809_1Type: ERR
User/Role: User of GloExplorer
Description: An Object cannot be saved if the second of two referenceable objects is referenced.
Solution: In int DataStreamer::streamAttributeListBlobInRecord(...) (in GloRecordAttributeFunctions.cpp) the parsing of the blob for references has been changed. The error was that queries for the content of references were incorrect. For example, for a reference that points to something, information about the record of the referenced object is in the XML file. If nothing is referenced, then this information is missing. If, after the reference to nothing, there is another reference that points to an object, the information there will be found.
The method mentioned above receives information about how the blob should be evaluated. Either an object ID is set or an entire record is created. In one case, this information is no longer used, but the blob is evaluated. If it is a valid object ID, only that will be set. Otherwise, if necessary, a record.
Status: Bug fixed for version 0.2.0 (2021.08.10 14:45)
GloExplorer: When an object is changed, there are memory leaks.
ID: 20210707_1Type: ERR
User/Role: User of GloExplorer
Description: When an object is modified via the GloQtExplorerGenericPersistentProp, there are memory leaks.
Solution: In void GloQtIntGenericPersistent::updateData() a list of glo::BaseRecordAttribute is fetched, for which the reference count is incremented.
When inserting into the GloQtIntGenericPersistent::m_AttributeList via void GloQtIntBaseRecordAttribute::setBaseRecordAttribute( glo::BaseRecordAttribute * pModelObject ) If the glo::BaseRecordAttribute is passed, the reference counter is also incremented.
The reference count of the fetched glo::BaseRecordAttribute is only decremented if it is not assigned.
That was changed; The reference count from the fetched glo::BaseRecordAttribute is decremented in any case.
Status: Bug fixed for version 0.2.0 (2021.08.10 14:45)
GlobalObjects version 0.1.9 (2021.06.15 16:20)
GlobalObjects: If an object is loaded multiple times from an AllSet, there are memory leaks.
ID: 20210608_1Type: ERR
User/Role: User of GlobalObjects
Description: If an object is loaded multiple times from an AllSet, there are memory leaks, but not if objects are loaded multiple times from an Ondemand, for example.
Solution: The fetched record was not removed from memory in an AllSet if the object already exists.
Status: Bug fixed for version 0.1.9 (2021.06.15 16:20)
GloExplorer: Explorer crashes when an object is in editeding and changed or deleted by others.
ID: 20210526_1Type: ERR
User/Role: User of GloExplorer
Description: An Object in the editing window is changed by another client. The user receives an indication as to whether he wants to transfer data. If the object is now deleted from another client, the user will receive the next display with the offer to close the editing window. If he does that, the first display has a dead parent; that was it!
Solution: All displays are removed before closing the editing window.
Status: Bug fixed for version 0.1.6 (2021.06.15 16:20)
GlobalObjects: Reference::getReference(BasePersistent*&) does not return incorrect error code for any reference
ID: 20210423_1Type: ERR
User/Role: User of GlobalObjects
Description: The error "glo::ERR_NO_BASE" was returned for a NULL reference, the error "glo::ERR_NO_REFERENCE" is expected.
Status: Bug fixed for version 0.1.9 (2021.06.15 16:20)
GlobalObjects: Refresh brings incorrect data into transaction (only if local)
ID: 20210422_1Type: ERR
User/Role: User of GlobalObjects
Description: If in local mode (no server), an incorrect record is fetched from the transaction manager when saving in a nested transaction after the transactions are aborted.
Status: Bug fixed for version 0.1.9 (2021.06.15 16:20)
GlobalObjects: Automatic call of overridable methods before and after database action
ID: 20210420_1Type: EXT
User/Role: User of GlobalObjects
Requirement: An overridable method should be called before and after saving or deleting an object. It should be possible to transfer data from the method called first to the method called second.
Use: In order not to have to overwrite the method glo::BasePersistent::store(...) or glo::BasePersistent::deleteInBase(...), call them before and after their action creates an overridable method that the GlobalObjects user can override. Any necessary additional actions can be initiated there.
Acceptance criteria: The requirement is met when the overridable pre and post methods are called.
Status: Ready for version 0.1.9 (2021.06.15 16:20)
GlobalObjects version 0.1.8 (2021.03.31 15:32)
GloExplorer: Notify in Explorer occasionally causes a crash when an object is deleted from another client.
ID: 20210322_1Type: ERR
User/Role: User of GloExplorer
Description: When a client deletes an object via GloServer, other clients can be notified. When GloExplorer is notified of a deleted object and displays it, GloExplorer occasionally crashes with a NULL-Poiner Exception.
The reason is probably that the deleted object, in this case the QTreeViewItem, is accessed again after being removed from memory.
Solution: It is currently used to notify about a Qt signal. the QTreeViewItem to be removed is sent. This should be changed to such an extent that only the ObjID of the affected object is sent via the signal and the 'catching' slots themselves determine the object from the TreeView. If it's no longer there, that's good too.
Status: Bug fixed for version 0.1.8 (2021.03.31 15:32)
GlobalObjects: Container file not deleted when owning object is deleted.
ID: 20210319_2Type: ERR
User/Role: User of the GlobalObject
Description: When an object with a container of objects is deleted, the container file must also be deleted. However, this is not carried out.
Solution: The method TableWriterInterface::deleteObjectData(…) has been adapted accordingly.
Status: Bug fixed for version 0.1.8 (2021.03.31 15:32)
GlobalObjects: Container file is not deleted if empty.
ID: 20210319_1Type: ERR
User/Role: User of the GlobalObject
Description: When an object is saved with a container of objects, that container is saved as a file. When the container is emptied and the object is saved in turn, the container file should be deleted. However, this is not carried out.
Solution: In the method TableWriterInterface::updateInsert(…) the method LotRecordAttribute::getFormattedFieldContents(…) is called for the container attributes. This was incorrect and has been adjusted.
Status: Bug fixed for version 0.1.8 (2021.03.31 15:32)
GlobalObjects version 0.1.7 (2021.03.05 09:11)
GlobalObjects: Single references such as pointers, embedded or std::shared_ptr are not saved via the server!
ID: 20210215_1Type: ERR
User/Role: User of GlobalObjects
Description: Attempts to save objects with a reference to another object are rejected with the error message ERR_NO_CORRECT_STREAM_DATA.
Solution: Data was not included in the transfer XML. Has been repaired.
Status: Bug fixed for version 0.1.7 (2021.03.05 09:11)
GlobalObjects version 0.1.6 (Jan 25 2021)
GlobalObjects, when saving an object with sets or lists of persistent objects, the references are doubled.
ID: 20210107_1Type: ERR
User/Role: User of GlobalObjects
Description: The reference entries in the database were duplicated and deletion was no longer possible
Solution: Fixed an error in the distinction between persistent and generic persistent objects. For persistent objects, the attributes of generic persistent objects were also processed.
Status: Bug fixed for version 0.1.6 (Jan 25 2021)
GloExplorer, Error in the context menu of the selection dialog for referenced persistent objects.
ID: 20201107_1Type: ERR
User/Role: GloExplorer user
Description: The context menu of the selection dialog for referenced persistent objects only displays the entries without a name.
Solution: The method for displaying the entries (due to language switching) was never called. This left the menu entries without labels.
Status: Bug fixed for version 0.1.6 (Jan 25 2021)
GloExplorer. In the object editing dialog, the [Refresh], [Save], [OK] or [Cancel] buttons do not respond to the keyboard.
ID: 20201109_1Type: ERR
User/Role: GloExplorer user
Description: The buttons mentioned above can be selected using [TAP], but do not respond to the subsequent [ENTER] key.
Solution: Were set to 'autodefault' in the Qt Designer.
Status: Bug fixed for version 0.1.6 (Jan 25 2021)
GlobalObjects version 0.1.5
GloExplorer, reference of an object to another object cannot be removed
ID: 20201007_1Type: ERR
User/Role: GloExplorer user
Description: Reference from one object to another object cannot be removed (only) in server operation.
Solution: The problem lay in the GloAPointerRecordAttribute class, which, when belonging to a generic object (GloGenericPersistent), has a pointer to the referenced GloGenericPersistent in addition to the GloRecord. This was not removed when the reference value was set to NULL and was transferred when packaging for the TCP packet.
Status: Bug fixed for version 0.1.5
GloServer, crash when saving non-generic objects with references to other objects
ID: 20200824_1Type: ERR
User/Role: User of the GloServer
Description: Non-generic objects are not saved via the GloServer, the GloServer crashes. The XML data packet is incorrect.
Solution: The XML data package is adapted.
Status: Bug fixed for version 0.1.5
GloDeveloper, database referenced multiple times
ID: 20200728_1Type: ERR
User/Role: GloDeveloper user
Description: A database can be transferred to a project several times, which does not make sense.
Solution: When inserting a database, it was not checked whether it was already in the project. This has now been implemented.
Status: Bug fixed for version 0.1.5
GloServer crash
ID: 20200504_1Type: ERR
User/Role: User of the GloServer
Description: If an empty set derived from GloBaseLot is to be lured, the GloServer crashes.
Solution: During the Tcp transfer, an empty set was transferred as 0 and then accessed as std::list! Has been fixed.
Status: Bug fixed for version 0.1.5
Translate GloDeveloper into English
ID: 20180919_3Type: EXT
User/Role: GloDeveloper user
Requirement: The GUI of the GloDeveloper should be translated into English using the Qt Linguist.
Benefit: GloDeveloper should be accessible to English-speaking users.
Acceptance criteria: The requirement is met if the GloDeveloper has an English GUI.
Status: Ready for version 0.1.5
Translate GloExplorer into English
ID: 20180919_6Type: EXT
User/Role: User of GloExplorer
Requirement: The GloExplorer GUI should be translated into English using the Qt Linguist.
Benefit: GloExplorer should be accessible to English-speaking users.
Acceptance criteria: The requirement is met if the GloExplorer has an English GUI.
Status: Ready for version 0.1.5
Translate GlobalObjects header documentation into English
ID: 20200330_1Type: EXT
User/Role: User of GlobalObjects
Requirement: The documentation in the headers for doxygen should be translated into English.
Benefit: GlobalObjects should be accessible to English-speaking GloDeveloper users.
Acceptance criteria: The requirement is met if all documentation in the headers for doxygen is in English.
Status: Ready for version 0.1.5
Translate GlobalObjects manuals into English
ID: 20200330_2Type: EXT
User/Role: User of GlobalObjects
Requirement: The documentation in the manuals should be translated into English.
Benefit: GlobalObjects should be accessible to English-speaking GloDeveloper users.
Acceptance criteria: The requirement is met if all documentation in the manuals is in English.
Status: Ready for version 0.1.5
GlobalObjects version 0.1.4
Adapt and deliver GlobalObjects to Visual Studio 2019
ID: 20200307_1Type: EXT
User/Role: Development user of GlobalObjects
Requirement: It should be possible to use GlobalObject fully with VS 2019.
Benefit: Adaptation of GlobalObjects to the new C++ IDE from Microsoft.
Acceptance criteria: The requirement is met if GlobalObjects works with all tools in conjunction with VS 2019.
Status: Ready for version 0.1.4
Adapt GlobalObjects to Visual Studio 2019; Errors are hailing down
ID: 20200317_1Type: ERR
User/Role: Development user of GlobalObjects
Description: When compiling with Visual Studio 2019, errors are thrown regarding "xstring" due to use of an unknown type.
Solution: Included in 'GloObjID.h' 'sstream'.
Status: Bug fixed for version 0.1.4
Index is evaluated incorrectly
ID: 20200112_1Type: ERR
User/Role: Development user of GlobalObjects
Description: When passing an index to an AllSet, the expected result is not returned.
Status: Bug fixed for version 0.1.4
If several clients read in a lot of data in multi-user operation, the server will stop at some point
ID: 20200314_1Type: ERR
User/Role: Development user of GlobalObjects
Description: The server gets 'stuck' in an endless loop when many requests arrive.
Status: Bug fixed for version 0.1.4
GlobalObjects version 0.1.3
Index with an attribute from superclass crashes
ID: 20190722_4Type: ERR
User/Role: Development user of GlobalObjects
Description: If a filter is set in the AllSet by an index that has an attribute from the superclass, the application crashes.
Status: Bug fixed for version 0.1.3
Index with integer does not work as a filter
ID: 20190727_1Type: ERR
User/Role: Development user of GlobalObjects
Description: If a filter is set in the AllSet by an index that is an integer, no object is found when iterating, even though the input is correct.
Status: Bug fixed for version 0.1.3
GlobalObjects version 0.1.2
time_t is incorrectly determined from the database
ID: 20190716_1Type: ERR
User/Role: Development user of GlobalObjects
Description: When reading objects from GlobalObjects, any attribute of the type 'time_t' should be used to determine the correctly localized time (currently the time is offset by 2 hours ).
Status: Bug fixed for version 0.1.2
GlobalObjects version 0.1.1
Create index in GloDeveloper
ID: 20181007_1Type: EXT
User/Role: Development user of GlobalObjects
Requirement: It should be possible to define an index from its attributes for a persistent class in GloDeveloper.
In order to speed up the finding of objects in the object database, all objects are now automatically indexed via a GloObjID. In addition, indexes should be able to be defined for each persistent class from its attributes, including inherited ones and attributes from referenced classes.
Benefit: If an index can be defined, GlobalObjects can be extended to create that index.
Acceptance criteria: The requirement is met if an index is defined in the database schema.
Status: Ready for version 0.1.1
Evaluate and save index in the schema
ID: 20181007_2Type: EXT
User/Role: Development user of GlobalObjects
Requirement: GlobalObjects should be expanded so that it can evaluate the index information and update it when a corresponding object is saved or deleted.
Benefit: If an index can be created, objects can be found quickly. There is additional benefit if the index can be used as a filter in an AllSet.
Acceptance criteria: The requirement is met if the index is updated when an object is saved or deleted.
Status: Ready for version 0.1.1
Evaluate index in AllSet as a filter
ID: 20181007_3Type: EXT
User/Role: Development user of GlobalObjects
Requirement: GloBaseAllSet and GloTAllSet should be expanded so that it is possible to set a filter. In the first version, the following filters are installed:
1. A search string should be able to be passed, if necessary with placeholders '*' and '?', which are taken into account in the evaluation. For example, the search string "H*|Me?er" should return all 'Meier', 'Meyer' or 'Meger' whose first name begins with an 'H' by AllSet when iterating.
2. A search string and comparison operator should be able to be passed. For example, if the search string has the value "123" and the comparison operator has the value '<'', all objects with an index less than 123 will be returned.
3. It should be possible to pass two search strings, a start and an end value. Only those objects should be delivered whose index is '>=' the start value and '<=' the end value.
Benefit: A dedicated index query does not have to be sent, but the AllSet delivers the desired objects.
Acceptance criteria: The requirement is met if the AllSet takes all filters into account when iterating.
Status: Ready for version 0.1.1
Enable index query in AllSet
ID: 20181007_4Type: EXT
User/Role: Development user of GlobalObjects
Requirement: GloBaseAllSet and GloTAllSet should be extended so that it is possible to call an index query. The following index calls are included in the first execution:
1. A search string should be able to be passed, if necessary with placeholders '*' and '?', which are taken into account in the evaluation. For example, the search string "H*|Me?er" should be returned by AllSet for all 'Meier', 'Meyer' or 'Meger' whose first name begins with an 'H'.
2. A search string and comparison operator should be able to be passed. For example, if the search string has the value "123" and the comparison operator has the value '<'', all objects with an index less than 123 will be returned.
3. It should be possible to pass two search strings, a start and an end value. Only those objects should be delivered whose index is '>=' the start value and '<=' the end value. 4. It is now possible to issue index queries for 'inherited' indexes.
Benefit: Objects can be quickly found using their index without having to iterate through the AllSet.
Acceptance criteria: The requirement is met if the AllSet enables all of the listed index queries.
Status: Ready for version 0.1.1