Bearbeitung von Daten
Über
Seit der Version 4.0.9 steht ein neuer Editor und damit ein neues Zugriffsverfahren für die Datenbearbeitung zur Verfügung.
Intern erfolgt dies über den neuen WellknownType "AnyDatasource", dieser Begriff taucht ggf. in der Beschreibung ab und an auf.
Ziel ist die Schaffung einer einheitlichen Schnittstelle zu den Daten und vor allem auch den Bearbeitungsmöglichkeiten. Damit kann gKK ersetzt, GEdit erweitert und Tabellen aus dem Datenbrowser erstmalig genutzt werden.
In cardo4 erfolgt die Integration derzeit an zwei Stellen.
- im Datenbrowser (wenn eine Lizenz für Upload vorhanden ist)
- für Ebenen, die im cardo3 Managementcenter als bearbeitbar mit dem (neuen) Attribut "cardo4 AnySource verwenden" eingestellt sind (wenn eine Lizenz für GEdit vorhanden ist).
Nahezu alle Einstellungen werden in dem (jetzt stark erweiterten) Einstellungsdialog für "Ebenen"-Attribute hinterlegt. Dies folgt der Logik der Gleichbehandlung von sonstigen Quellen und den administrativ eingestellten Ebenen.
So sieht der Editor aus:
Allgemeine technische Festlegungen
Folgende Vorbedingungen müssen erfüllt sein, damit die Bearbeitungsfunktionen genutzt werden können:
Datenspeicher (z.Z. implementiert):
- PostgreSQL (ab Version 9.6)
- Oracle (ab Version 10)
- Microsoft SQL Server (ab Version 2008)
Alle Geometrien (sofern vorhanden) müssen mit einer SRID gespeichert sein. Der Editor speichert immer mit SRID, bei Oracle nicht die SDO ID, sondern immer als EPSG-Code.
Das bedeutet auch, dass bereits vorhandene Geometriedaten in der Quelle ebenfalls diese Anforderung erfüllen müssen.
Zurzeit wird bei mehreren Geometriespalten davon ausgegangen, dass alle in der gleichen Projektion vorliegen (später wird es eine Einstellung des Bezugssystems pro Spalte geben).
Oracle: "Kleines entgegenkommen": Wenn in der SDO_GEOM_METADATA Tabelle SRID NULL für die Spalte gefunden wird, dann wird auch NULL als SRID gespeichert.
Die Tabelle muss über eine Spalte mit einem eindeutigen, numerischen Autowert verfügen. Dieser muss nicht zwangsläufig der Primary-Key sein. In den Einstellungen kann die Spalte als "Primary" markiert werden. Bei den meisten Datenbanken ist das kein Problem, bei Oracle (vor Version 12) wird der Autowert ermittelt durch ...
das Auslesen der Triggerdefinition für die entsprechende Tabelle
im SQL Code des Triggers nach :new. und .nextval() suchen, der Teil nach :new.XXX wird dann der Spalte zugeordnet. Folgender Trigger entspricht dem Vorgehen und würde colName als serial identifizieren:
create or replace trigger trg_id_tab before insert on "SCHEMA"."TAB" for each row begin if inserting then if :NEW."COLNAME" is null then select XYZ_SEQ.nextval into :NEW."MSLINK" from dual; end if; end if; end;
die Ids müssen > -10000000 sein (für neue Datensätze beginnen wir mit einer negative Id, damit es nicht mit den vorhandenen kollidiert dieser Hinweis.)
Es werden (z.Z.) nicht alle Typerweiterungen der jeweiligen Datenquelle unterstützt, z.B. keine Arrays-Typen in Postgres, keine benutzerdefinierten Typen außer Geometrien, GUIDs, Domänen usw.
Bei Views können die Spalteneinstellungen nicht alle ermittelt werden, bspw. ob die Spalte ein Autowert ist, in diesem Fall müssen Sie in den Einstellungen der Datenquelle (Bereich Bearbeitungseinstellungen) die Spalte als "Primärer Wert" und "Ist Autowert" markieren. Dabei muss dies in der Datenbank natürlich auch zutreffen.
Datenbanken die case-sensitiv eingestellt sind (Unterscheidung Groß/Kleinschreibung bei Objektnamen) werden nicht offiziell unterstützt.
Geometrien werden nur in Form "echter" Geometrietypen akzeptiert, z.Z. ist keine Implementierung für Punktgeometrien als Rechts-/Hochwert verfügbar.
Speicherung der Einstellungen
Die AnyDatasource verwendet für die Adressierung der Objekte eine Protokolldefinition mit folgendem Aufbau:
protocol://connection::ObjectName
protocol: Ein im System registrierter Handler für den Umgang mit der Datenquelle (eine Klasse, die C# Interface
IduIT.Core.Data.DsAL.IAnyDatasource
implementiert)connection: je nach Protocol-Handler
ObjektName: je nach Protocol-Handler (z.B. schema.tabelle oder L815 bei Ebenen)
Dieser Identifikator wird auch für die Speicherung der Einstellungen verwendet.
Die Daten sind in der cardo Datenbank in der Tabelle cdo4_settings gespeichert. Der settings_type_name ist dabei immer "IduIT.cardo.Core.Environment.Content.LayerDataSettings.LayerDataSettings", der variant_name entspricht dem Identifikator der Datenquelle.
Da eine lose Koppelung zwischen den Einstellungen in cardo und den eigentlichen Objekten besteht, d.h. cardo bekommt von Änderungen an der Datenbank nicht unmittelbar etwas mit, kann im Falle des z.B. Umbenennens der Objekte (z.B. Tabellename) hier manuell der Wert in variant_name angepasst werden.
Vorgehen
Bei der Verwendung einer so adressierten Datenquelle werden intern folgende Vorgänge ausgelöst:
Abrufen der Beschreibung des Objektes vom Protocol-Handler (Berechtigungen, Titel, Fähigkeiten, etc. der Quelle)
Übersetzen der Berechtigungen aus der Datenquelle (z.B. Geo-Edit-Ebene) auf das allgemeine Rechtesystem *1)
Abrufen der Spalteninformationen direkt aus der Datenquelle. Das ist je nach Datenbank recht unterschiedlich. Hier werden Datentypen, Nullable, PK, Autowert etc. ermittelt, z.Z. werden diese Informationen bei jedem Zugriff neu ermittelt.
Zusammenfassen der technisch ermittelten Beschreibung mit denen, die in den Einstellungen hinterlegt sind (sofern vorhanden).
Je nach Berechtigungen werden im cardo dann die entsprechenden Möglichkeiten angeboten: Anzeigen, Bearbeiten, Einstellungen ändern.
Datenbearbeitung
Die Bearbeitung erfolgt in einer generischen Anwendung, die sich aus den Einstellungen generiert. Hier sollen nur kurz die technischen Vorgänge dargestellt werden, die Bedienanleitung für die Nutzer finden Sie separat im Hilfebereich.
Es gibt pro Datenquelle immer genau einen Editor. Dieser wird immer in einem eigenen Fenster geöffnet. Der Editor selber ist unterteilt in eine Datenliste und ein Bearbeitungsformular.
Wir haben keine Bearbeitung in der Liste vorgesehen, diese dient nur der Anzeige / schnellen Suche.
Die Datenliste enthält mindestens die ID, wenn Spalten angegeben sind, dann wird die ID nicht mehr automatisch hinzugefügt und muss explizit gewählt werden.
Wenn Daten aus dieser Quelle zur Bearbeitung ausgewählt werden, bspw. aus dem Maptip oder der Selektion heraus, dann werden die Datensätze ermittelt und, wenn noch nicht vorhanden, der bestehenden Editorinstanz hinzugefügt.
Die Daten im Formular werden pro Datensatz beim ersten Zugriff nachgeladen, dann auf dem Client gecacht. Neu geladen werden diese Daten erst nach dem Schließen des Editors und nach dem Speichern.
Der Editor übermittelt beim Speichern für jeden Datensatz nur die tatsächlich geänderten Feldwerte.
Die Suche innerhalb des Editors findet nur in den aktuell in der Listenansicht vorhandenen Daten statt.
Nutzung des Datenbrowsers
Das Protokoll für den Datenbrowser ist 'dbdb', der Verbindungsname ist der im Datenbrowser eingestellte Alias oder die ID der in den cardo Systemeinstellungen hinterlegten Datenbank.
Bsp.: dbdb://DBALIAS1::schema.tabelle
Das bedeutet:
- wenn der Alias oder die ID geändert wird, dann werden die vorgenommenen Einstellungen nicht mehr gefunden, auch wenn diese auf die gleichen Daten zeigen.
- wenn im Datenbrowser die physisch gleiche Datenbank mit verschiedenen Aliasen angelegt wird, dann sind es aus cardo Sicht trotzdem verschiedene Objekte.
- eine Ebene (siehe unten, Nutzung GEdit Ebenen) die auf eine der Tabellen in dieser Datenbank zeigt, ist auch ein anderes Objekt.
Aus der Tabelle kann auch eine Ebene generiert werden, sofern eine Geometriespalte vorhanden ist. Beachten Sie, dass der Epsg-Code entsprechend eingestellt sein muss. Dies ist in dem Einstellungsdialog vorzunehmen.
Nutzung von GEdit-Ebenen
Für die im Geoeditor eingestellten Ebenen wird intern parallel dazu eine Instanz eines "AnyDatasource" erstellt.
Damit sind die Einstellungen für die Ebene nicht identisch mit denen der Bearbeitungsebene.
Das scheint auf den ersten Blick etwas aufwendig, müssen doch die Attribute manuell übernommen werden. Im Gegenzug gibt es aber eine sauberere Trennung zwischen der eingestellten Quelle in der Ebene (oft eine Abfrage) und der eigentlich hinterlegten Tabelle (einstellbar in den Editor-Einstellungen im Managementcenter).
Die Bearbeitungsebene verwendet intern den hinterlegten Tabellennamen der Ebene oder den eingestellten alternativen Tabellennamen.
Außer dieser Einstellung und der für die Ebene hinterlegten EPSG werden keine weiteren Eigenschaften aus dem Managementcenter verwendet. Die EPSG Einstellung im Einstellungsdialog der Quelle wird ignoriert.
Die Einstellungen werden gespeichert mit dem Schlüssel der Ebene und dem Protokoll "edlyr" (Bspw.: "edlyr://::L965").
Anhang
*1) AnyDatasource kennt z.Z. diese Rechteeinstellungen:
public enum DataObjectRights
{
/// <summary>
/// Keine Rechte an den Daten
/// </summary>
None = 0,
/// <summary>
/// Daten lesen
/// </summary>
ReadData = 1,
/// <summary>
/// Bestehende Datensätze ändern
/// </summary>
ModifyData = 2,
/// <summary>
/// Neue Datensätze erstellen
/// </summary>
CreateData = 4,
/// <summary>
/// Vorhandene Datensätze löschen
/// </summary>
DeleteData = 8,
/// <summary>
/// Darf diese Datenquelle verwalten
/// </summary>
Admin = 16
}
Neben diesen Berechtigungen gibt es noch Restriktionen, die das Bearbeitungsrecht auf Zeilen einschränken können.
/// <summary>
/// Berechtigungen auf Zeilen-Ebene, WriteData muss in Kombination mind. gewährt sein
/// </summary>
[Flags]
public enum RowLevelRestrictions
{
/// <summary>
/// Keine weitere Restriktionen auf die Zeilen
/// </summary>
NoRestrictions = 0,
/// <summary>
/// Es dürfen nur Zeilen bearbeitet werden, wo der Nutzer als Creator enthalten ist, entsprechend muss eine Spalte vom speziellen Typ <see cref="IduIT.Core.Data.ORM.SpecialColumn.CreatorColumn"/> vorhanden sein.
/// </summary>
RestrictedToModifySelfCreatedRows = 1
}
Zuletzt geändert: 24.09.2024 17:54:52 (erstmals erstellt 06.09.2018)