EMF mit OO-DB?

[virtuellesNugat]

Hallo

Unser Programm nimmt Formen an und wir würden am liebsten unsere Speicherfunktion als Speichervorgang in eine OO-DB (DB4o) realisieren.
Wir haben die gesamte Datenhaltung mit EMF realisiert. Als wir fertig waren haben wir jetzt versucht, den jeweiligen Zustand in eine DB4o DB zu sichern.
Das klappt allerdings nicht, DB4o fordert offenbar jede zu verwaltende Klasse selber per Konstruktor erstellen zu können. Weil EMF aber mit Singletons und Fabriken arbeitet, weigert sich DB4o damit zu arbeiten. Nach vielem vergeblichen Suche dachte ich mir, wende ich mich doch gleich an euch

Also stellen sich mir zwei Fragen:

1. Ist es möglich in DB4o EMF Objekte zu sichern - wenn ja wie?
2. Das ist vermutlich auch gar keine schöne Art zu speichern. Wie würdet ihr die Objekte speichern? Wir nutzen EMF und RCP zur Darstellung. Da wäre der Gedanke, das Projekt Objekt (mit allen Informationen) einfach in einer DB abzulegen ja schon sehr bequem. Funzt nur leider nicht..

Wäre euch echt dankbar.. langsam krieg ich ne Krise

Viele Grüße!

 

[code404]

Also zu DB4o und EMF kann ich nichts sagen.
Aber für die globale Speicherung von EMF Objekten in einer DB ist Teneo oder CDO dein Freund.
Vielleicht lohnt auch ein Blick Richtung EMFStore.

 

[virtuellesNugat]

Hi,

danke für deine Antwort. Diese Technologien sind mir auch schon über den Weg gelaufen. Wir haben die Speicherung jetzt über die XMIRessourceFactory gelöst. Bot sich ja irgendwie an

Dieses Forum ist einfach klasse, würde gerne mehr Zeit hier verbringen. :toll: Lässt nur die FH nicht so zu wie ich das gern hätte

 

[Gast2]

Ich habe 2 Sachen bis jetzt privat ausprobiert:
1. Versuch Teneo
Wenn du eine Standalone RCP Andwendung hast ist Teneo ganz gut um deine orm.xml aus dem ecore Model generieren zu lassen:

Aufbau/Schichten der Andwendung war: Eclipse RCP-->Service (Spring für Transaktionen)-->JPA(EclipseLink,Spring)-->Db (Derby,H2)
EMF hat die Models generiert und Teneo die orm.xml

2. Versuch mit Server
Wenn man einen Server benutzt hatte ich Probleme die EMF Models zu serialiseren.
Darum habe ich EMF Texo verwendet habe (Empfohlen bekommen ). Mit Texo kann man aus dem Ecore Model Pojos generieren lassen und daraus die orm.xml.
Außerdem wurde aus dem Ecore Model die Client Models mit EMF generiert, damit ich im RCP Undo/Redo Support, Notification Framework und die restlichen Vorteile nutzen kann.

Es gibt auch schon vorgefertigte Klassen um die EMF Texo Pojos in EMF Model zu konvertieren.
Ich habe die serialisierung von Server zum Client über XMI realisiert. Aber hier weiß ich nicht ob es nicht etwas besseres gibt, da es eine ziemliche Casterei war denk ich, dass es in der Schicht was besseres gibt. Soviel ich weiß will EMF Texo bald JSON verwernden, vielleicht wird es damit besser.

Also die Komponenten/Schichten waren auf dem Server Seite DB (Derby)--> JPA(EclipseLink,Spring) -->Service mit Transaktionen(Spring)
das Model Bundle wurde mir EMF texo erstellt und daraus wurde die orm.xml generiert.

Auf Client Seite wurden die Models mit EMF generiert Eclipse RCP -->Service Aufruf(Spring HTTP Invoker)

Wie gesagt für die Konvertierung Schicht fehlt mir noch die passende Lösung. Hatte auch keine Zeit mehr das weiter zu verfolgen.
Ich habe immer XMI Files hin und her geschickt und in den entsprechenden Services immer Texo <--> EMF Konvertiert und dort auch viel casten müssen. Denke da gibt es eine bessere Lösung wo man sowas zentral abhandeln sollte.

Noch eine Idee wäre es Wenn man einen Server/Client Anwendung realisieren will.
Das man EMF/Teneo verwendet und die Serialsierung auch über XMI realisiert.
Hab ich noch nicht versucht, das ich Teneo nicht so prickelnd fand auch von der Usability. Und Teneo setzt nicht auf JPA2.0 auf was Texo hingegen schon macht.
Wie ich mitbekommen habe wird Texo auch weiter entwicklet und voran getrieben, wobei bei Teneo nicht mehr viel gemacht wird.

CDO habe ich mir noch nicht angeschaut wäre eventuell auch noch eine schöne Variante...

 

[Gast2]

Hi,

danke für deine Antwort. Diese Technologien sind mir auch schon über den Weg gelaufen. Wir haben die Speicherung jetzt über die XMIRessourceFactory gelöst. Bot sich ja irgendwie an

Dieses Forum ist einfach klasse, würde gerne mehr Zeit hier verbringen. :toll: Lässt nur die FH nicht so zu wie ich das gern hätte

Klar wen du keine DB benötigst und die Daten nur lokal halten willst bietet es sich an, kommt auf deine Datenmenge an.

 

[virtuellesNugat]

Das soll eine lokale Literaturverwaltung sein. Also sind das (was die Modelldaten angeht), wohl so:
n * 20 Attribute, welche nicht weiter komplex wären.

Und sorry, dass du jetzt (wie es den Anschein hat), angefangen hattest zu schreiben bevor ich fertig gepostet hatte, aber deine Arbeit war ja nicht ganz umsonst Danke!

 

[Gast2]

Das soll eine lokale Literaturverwaltung sein. Also sind das (was die Modelldaten angeht), wohl so:
n * 20 Attribute, welche nicht weiter komplex wären.

Und sorry, dass du jetzt (wie es den Anschein hat), angefangen hattest zu schreiben bevor ich fertig gepostet hatte, aber deine Arbeit war ja nicht ganz umsonst Danke!

Vielleicht wächst Sie ja noch und bleibt nicht immer lokal

 

[virtuellesNugat]

Wahrscheinlich schon, weil es ein Nachbau einer existierenden Software für die FH ist Aber wenn ich mal wieder was "für mich" entwickeln kann, dann würde ich nämlich gerne auf diese Kenntnisse zurückgreifen.