Date: prev next · Thread: first prev next last
2018 Archives by date, by thread · List index


Hallo Robert,

Wenn ich ganz ehrlich sein kann, dann bin ich sehr erschrocken, dass
Tabellen und Views (da gibt es nicht wirklich einen deutschen Fachbegriff)
nicht transferiert werden.
Das Problem hier ist, dass eigentlich gar nichts funktioneirt. Denn
Relationen zwischen Tabellen, persistierte Views (Tabellen) und virtuelle
Views ( eben die Views / Ansichten) sind genauso wie die folgenden Sachen
grundfunktionen und müssen transferiert werden:

INDEX, Primärschlüssel (über ein Feld und über mehrere Felder), UNIQUE (und
andere) Konstraints wie "NICHT NULL".

Ich glaube, dass es sinnvoll wäre ein Dokument mit allen Features zu
erstellen und zu beschreiben, was da sein soll (Tabelle mit Primärschlüssel
X, Y ist der Sekundärschlüssel für die Relation zur Tabelle Z). Damit
hätten wir einen sehr wichtigen Aspekt angegangen.

Danach müssen wir sicherstellen, dass alle automatisch generierten SQL
Queries funktionieren. Da kann es zu gröberen Problemen kommen, wenn der
SQL Standard nicht gleich implementiert ist.

Ich würde sagen, dass eine Umstellung erst dann passieren soll, wenn dies
und zusäztlich natürlich echte Base Dokumente getestet wurden und sie
funktionieren. Aber ich glaub momentan wäre es gut ein Dokument zu haben,
wo man sieht was alles nicht geht.... (Mit sehr wenigen bis gar keinen
Daten drinnen.)

3) Ich muss sagen ich komme aus der Java Welt und da wurde - trotz
deprication - noch nichts nennenswertes entfernt. Darum wäre ich eigentlich
dafür HSQLDB mit 6.1 als Deprecated zu markieren und mindestens 3 Releases
als Übergangsperiode zu definieren. 3 Releases später wird Firebird default.

@Robert: Sind die Fehler hier aufgrund der Konvertierung. Firebird selbst -
also wenn man eine ODB mit dem erstellt. Kann man das gut verwenden oder
sind wir auch da nich nicht weit genug..?


Danke für deine Antworten. Bin schon sehr auf deine Test Ergebnijsse
gespannt.

lg

Florian

Robert Großkopf <robert@familiegrosskopf.de> schrieb am Fr., 13. Apr. 2018,
08:05:

Hallo Florian,

Ich bin etwas verwirrt, wenn nicht Mal Views übernommen werden sollen....
Laut dem ESC call könnte es eine 2-3 jährige Übergangszeit geben, also
dass
das nächste LTS Release der Linux Distributionen abgewartet wird.

Ich habe diesen Call auch gelesen. Die Übergangszeit würde schon passen.
1. Schritt: Firebird aus dem Experimentalstadium raus.
2. Schritt: HSQLDB nach Firebird migrieren (wenn Firebird stabil genug
und begründbar besser funktioniert - nicht wenn Firebird Probleme mit
Funktionen hat, die HSQLDB bietet.
3. Schritt: HSQLDB als Deprecated einstufen. Dann sind wir aber auf
jeden Fall raus aus der Abwärtskompatibilität. Der Austausch der
*.odb-Dateien zwischen neueren LO-Versionen und älteren LO-Versionen und
auch AOO ist nicht mehr möglich.
4. Schritt: HSQLDB raus - so wie es jetzt bei der "Migration" versucht
wird/wurde.

Ich finde es eigentlich eine verlorene Chance, dass nicht bei jedem
Dokument, das konvertiert wird zumindest "select * from <name>"
verglichen
wird, ob das gleich ist. Denn wenn die Daten passen ist der automatische
Teil der Migration fertig, das SQL anzupassen geht nicht wirklich, oder?

Was im Augenblick bei der Migration vermutlich funktioniert ist die
Erstellung der Tabellen mit Daten, wenn die Beziehung zwischen den
Tabellen nicht definiert wird. Das Gleiche erzeuge ich aber auch, wenn
ich einfach Tabellen von der einen Datenbank in die andere ziehe. Da
mache ich das dann bewusst.

Sobald Beziehungen zwischen den Tabellen definiert werden bekomme ich
kein Migrationsergebnis, wenn die Tabellen Inhalt enthalten - so
zumindest bei meinen Tests.

Wenn Beziehungen definiert sind und die Tabellen leer (kommt bei einer
Migration wohl nicht vor), dann werden die Tabellen erstellt, die
Tabellen in den Beziehungen aber nicht verknüpft.

Ansichten werden grundsätzlich raus gelassen, egal wie kompliziert sie
sind. Der SQL-Code von Views ist nicht so sehr unterschiedlich. Das
Dumme ist nur, dass der von der Datenbank überprüft wird. Sollte das
fehl schlagen, dann könnte als Alternative der SQL-Code des Views als
Abfrage in die zu migrierende Datenbank übernommen werden. Sonst ist
nämlich der gesamte Code verloren. Ich habe hier views, die eben nicht
nur eine Zeile, sondern nahezu eine A4-Seite beinhalten - die weiß ich
doch nicht auswendig.

Leider funktioniert in der aktuellen 6.1 der Editor für Views nicht
einmal. Stattdessen wird bei einem View der Tabelleneditor geöffnet.
Views lassen sich nur über Abfragen erzeugen und dann als Ansichten in
den Tabellencontainer übernehmen.

Ich habe spontan nur die Standarddatenbank des Handbuches an dieser
Migration versucht und dann von dieser her abgespeckt. Am Wochenende
werde ich etwas mehr testen. Bisher habe ich es nicht geschafft, eine
Datenbank mit allen Daten migriert zu bekommen - nicht weil ich Views
drin habe, sondern weil ich natürlich Beziehungen definiert habe und
meine Tabellen auch bei Testbeispielen natürlich Inhalt enthalten. Die
Datei enthält nach der Migration keine Tabellen mehr.

Gruß

Robert
--
Homepage: http://robert.familiegrosskopf.de
LibreOffice Community: http://robert.familiegrosskopf.de/map_3

--
Liste abmelden mit E-Mail an: discuss+unsubscribe@de.libreoffice.org
Probleme?
https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/discuss/
Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert

-- 

Mit freundlichen Grüßen, | Yours,
Florian Reisinger

-- 
Liste abmelden mit E-Mail an: discuss+unsubscribe@de.libreoffice.org
Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/discuss/
Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.