Einleitung

GlobalObjects ist eine C++ objektorientierte Datenbank (OODB, ODBMS, NoSQL) um C++ Objekte persisten zu halten. Es ist Single- und Multiuserbetrieb über einen Server möglich.

Es können C++ Objekte gespeichert, geladen und auch wieder gelöscht werden. Dieses kann auch in Transaktionen stattfinden, welche bestätigt (Aktionen werden ausgeführt) oder abgebrochen werden können (Aktionen werden nicht ausgeführt). Das ACID-Prinzips wird konsequent eingehalten.

GlobalObjects versteht C++-Klassendeklarationen mit Unterstützung für Kapselung, Vererbung, Polymorphismus, Objektidentität und Objektreferenzen.

Es existiert ein umfangreicher Sperrmechanismus um gespeicherte Objekte zu schützen.

Um Änderungen am Objektbestand "mitzubekommen", kann ein einfaches Benachrichtigungssystem, realisiert durch Übergabe einer Callback-Funktion, genutzt werden.

Das Hauptaugenmerk liegt im einfachen Abspeichern und Laden von auch komplexen C++ Objekten mit deren Referenzen und der Aktualisierung von geladenen Objekten im Speicher, wenn diese in der Datenbank geändert werden.

Die Bezeichnung GlobalObjects wurde gewählt, weil es den Entwickler dabei unterstützt, Objekte auf mehreren Clients automatisch zu synchronisieren. Die mit GlobalObjects entwickelte Applikation funktioniert dennoch ohne Änderung auch im Einzelplatzbetrieb.

GlobalObjects ist daher keine geschwindigkeitsoptimierte Datenbank. Jede Klasse besitzt ihre Tabelle (eine einfache Textdatei) mit mindestens einem Objekt-ID-Index. Objekte einer Klasse mit vielen Superklassen werden durch Einlesen der jeweiligen Datensätze „zusammengebaut“ bzw. beim Speichern „zerlegt“. Komplexe Objekte mit Referenzen auf andere Objekte, die ebenfalls gespeichert oder gelöscht werden müssen, können sich daher negativ auf das Timing auswirken. Indizes werden aus dem Dateisystem in Objekte vom Typ std::map<T> eingelesen bzw. beim Schließen der Anwendung wieder ins Dateisystem zurückgeschrieben.

Zurzeit werden Microsoft Visual Studio (ab Version 2010) sowie MinGW (ab Version 5.3.0) unter Windows und gcc (ab Version 4.8.3) und Clang (ab Version 6.0.0) unter Linux unterstützt. Man kann z.B. einen GloServer auf ein unterstütztes Betriebssystem installieren und auf diesen von allen unterstützten Betriebssystemen mit einer Client-Applikation zugreifen.

Alternativen um C++ Objekte zu speichern

Um C++ Objekte aus dem Speicher des Rechners persistent ablegen zu können, gibt es grob gesagt drei Möglichkeiten:

Serialisieren auf einem Datenträger wie z.B. einer Festplatte oder SSD.
Konvertieren in ein relationales Modell und dieses in einer konventionellen relationalen Datenbank abzulegen.
Direkt abspeichern in eine Objekt-Datenbank.

Konzept von GlobalObjects

GlobalObjects geht den Weg, das die C++ Objekte wie in einer Objekt-Datenbank gespeichert werden; die Ablage aber im Dateisystem eines Datenträgers vorgenommen wird. In einer späteren Ausbaustufe ist angedacht, die Ablage in einer SQL-Datenbank wie z.B. SQLite vorzunehmen zu können.

Ein Datenbankdesign muss bei GlobalObjects nicht vorgenommen werden.

Leistungsmerkmale

Hier ein kurzer Abriss der Möglichkeiten von GlobalObjects:

Speichern, laden und löschen

Mit GlobalObjects ist ein direktes speichern, laden und löschen von C++ Objekten in einer Objektdatenbank möglich. Es wird die einfache wie auch Mehrfachvererbung von C++ unterstützt. Es steht für jede Klasse ein AllSet (die Menge aller gespeicherten Objekte der Klasse) zur Verfügung. Beim Laden eines Objektes aus einem AllSet wird das echte Objekt instanziiert, welches ggf. abgeleitet sein kann (das Laden eines Objektes aus dem AllSet der "Tiere" instanziiert die jeweiligen Objekte z.B. vom Typ "Fisch" und "Vogel" etc.).

Es kann eingestellt werden, ob referenzierte Objekte mitgeladen, mitgespeichert oder mit gelöscht werden sollen.

Beispiel:

...
#include <GloBase.h>
// Die persistenten Klassen werden vom Objekt-Ersteller eingebunden.
#include "FirstBaseObjCreator.h"
...
MyFirstBaseObjCreator  t_ObjCreator;
glo::Base       t_Base( "LOCAL", "ClientName", "FirstBase", t_ObjCreator ); // ohne Server
// glo::Base      t_Base( "HOSTNAME", "ClientName", "FirstBase", t_ObjCreator ); // mit Server (HOSTNAME)
...
if ( t_Base.openBase() == 0 )
{
  int  t_iErr = 0;
 
  // Neues Objekt vom Typ FirstPersClass; glo::Forgeter<FirstPersClass>()wird mit übergeben
  std::shared_ptr<FirstPersClass>  t_NewPersObject( new FirstPersClass(), glo::Forgeter<FirstPersClass>() );
 
  // Das Objekt bei der Objektdatenbank anmelden, das Objekt bekommt eine gültige Objekt-ID (siehe glo::ObjID) und...
  if ( t_NewPersObject->assign( t_Base ) == 0 )
  {
    // ...einfach speichern. Wenn kein Fehler ist das komplette Objekt in der Objektdatenbank.
    t_iErr = t_NewPersObject->store();
  }
  ...
  std::shared_ptr<FirstPersClass>   t_PersObject;
  glo::TAllSet<MyFirstClass>        t_AllSet( t_Base );
 
  t_iErr = t_AllSet.get( t_PersObject, glo::START ); // holt erstes Objekt aus dem AllSet in t_PersObject
  // mach irgendwas mit  t_PersObject...
  ...
  // ... und speicher dieses wieder
  t_iErr = t_PersObject->store();
  ...
  // ... bzw. lösche dieses in der Objektdatenbank
  t_iErr = t_PersObject->deleteInBase();
  ...
  t_Base.closeBase()
}

Referenzen

Es werden Referenzen wie Zeiger, auch in Containern, auf andere Objekte in der Objektdatenbank zur Referenznavigation angeboten. Es kann eingestellt werden, ob die referenzierten Objekte mit dem Objekt mitgeladen (instanziiert) werden oder erst beim Zugriff auf diese (siehe auch glo::TOndemand, glo::TOndemandList und glo::TOndemandSet). Zudem kann eine Abhängigkeit eingestellt werden (dependent) so dass referenzierte Objekte z.B. mitgespeichert bzw. mitgelöscht werden. Mehr...

Sperrverfahren

Um Multiuserzugriffe zu gewährleisten, ist ein Sperrmechanismus bis auf Objektebene implementiert. Sowohl Mengen von Objekten wie auch einzelne Objekte können vielfältig gesperrt werden. Mehr...

Transaktionen

Um mehrere Objektdatenbank-Aktionen garantiert geschlossen vornehmen zu können, werden Transaktionen zur Verfügung gestellt. Es werden geschachtelte Transaktionen unterstützt. Mehr...

Beobachten und benachrichtigen

Damit Änderungen an Objekten in der Objektdatenbank von einer Applikation wahrgenommen werden können, um z.B. die Objekte im Speicher konsistent zu halten, ist ein einfachst zu nutzendes Benachrichtigungssystem vorhanden. Mehr...

Indexe

Um Objekte anhand von Attributwerten zu finden, ist es möglich Objekte über ihre Attribute zu indizieren Es ist möglich, Objekte über eigene Attribute, Attribute von Oberklassen und Attribute von referenzierten bzw. eingebetteten Klassen zu indizieren. Es können Attribute zusammengefasst werden wie z.B. "Name" und "Vorname" als ein Index-Attribut. Mehr...

Unterstützte Datentypen

Es werden die meisten Standardtypen als eingebettete Attribute unterstützt. Aktuell werden diese Datentypen für persistente Objekte zur Verfügung gestellt.

GlobalObjects Fehlercodes

Damit auftretende Fehler besser eingeordnet werden können, sind diese nach Bereichen geordnet.

Fehlerbereich = -10001 bis -10200
Für die Socket-Fehler (alle von -10004 bis -11004) sind Beschreibungen im Internet zu finden.
Für Windows Sockets z.B. unter: https://msdn.microsoft.com/de-de/library/windows/desktop/ms740668%28v=vs.85%29.aspx
oder allgemein auch unter: https://gist.github.com/gabrielfalcao/4216897
Aufzählung nicht vollständig!

Fehlerbereich = -13001 bis -13200

Fehlerbereich = -14201 bis -14300

Fehlerbereich = -15001 bis -15100

Fehlerbereich = -15501 bis -15600