DATEV/S-MIME „Secure-Email“ : Praktische Outlook Integration

Die Firma Datev hat für alle seine angeschlossenen Steuerberater ein E-Mail System mit automatischer Verschlüsselung zur Verfügung gestellt – fast alles wird verschlüsselt. Für Personen ausserhalb des Datev-Systems ist es aber nur wenig praktisch …

Weiterlesen
Veröffentlicht unter Security | Verschlagwortet mit , , , , | Kommentare deaktiviert für DATEV/S-MIME „Secure-Email“ : Praktische Outlook Integration

Snowflake: File format does not exist

Für das Laden von Dateien gibt es in Snowflake den COPY INTO Befehl. Der Befehl ist dazu gedacht – mit Hilfe eines File Formats – Daten aus der Datei in eine Tabelle zu kopieren. Aber auch ohne die Daten zu laden kann man einfache Selects auf Dateien ausführen.

Weiterlesen
Veröffentlicht unter Snowflake Computing | Kommentare deaktiviert für Snowflake: File format does not exist

Snowflake: Unsupported feature ‚Table‘

Das Laden von Dateien funktioniert in Snowflake via SQL mit direktem Zugriff auf einen Blob Storage via Stages. Hier ein Select auf CSV-Dateien in der persönlichen Stage mit einem nicht so leicht zu findenden Fehler:

SELECT metadata$filename, T.$1, T.$2, T.$3
FROM '@~/data' 
(
FileFormat => 'Db.kjeperti.CSV',
Pattern => ".*/[0-9]{8}.csv.gz$"
) t

Die Fehlermeldung ist dabei leider gar nicht hilfreich:

Unsupported feature ‘Table’

SELECT metadata$filename, T.$1, T.$2, T.$3
FROM '@~/data' 
(
File_Format => 'Db.kjeperti.CSV',
Pattern => ".*/[0-9]{8}.csv.gz$"
) t

Im richtigen SQL ist der Tippfehler bei „File_Format“ korrigiert. Es hat der „_“ gefehlt.

Veröffentlicht unter Snowflake Computing | Kommentare deaktiviert für Snowflake: Unsupported feature ‚Table‘

Sphinx: Unexpected unindent

Sphinx ist das Standardtool zur Dokumentation von Python Code. Sphinx liest direkt DocStrings aus dem Quellcode aus und bereitet dabei eine Dokumentation auf.

Ideal wäre es wenn das natürlich ganz ohne Änderungen am Code oder der Dokumentation abläuft und man nicht noch mehr syntatktische Regeln beachten muss.

WARNING: Block quote ends without a blank line; unexpected unindent.

Diese Fehlermeldung sagt allerdings etwas anderes. Dies ist ein Warning das Sphinx beim Kommando „make html“ ausgespuckt hat.

Ursache dafür war dieser Docstring mit Einrückungen:


def dummyfunction():

'''Das ist ein langer Kommentar mit mehreren Punkten:

   - Punkt1 : Lorem ipsum
     dolor il

   - Punkt2: ....

'''

....

Veröffentlicht unter Allgemein | Kommentare deaktiviert für Sphinx: Unexpected unindent

Oracle SQL: ungewollte Zeichen aus einem String entfernen

„All input is evil“ ist eine alte Weisheit. In der Praxis liefern Datenquellen die verschiedensten Überraschungen. Leerzeichen/Whitespaces am Anfang oder am Ende ist dabei noch am einfachsten zu finden. Wie aber nun ungewollte Zeichen aus einem String filtern ?

Die Funktionen Replace oder Translate bieten sich an, scheitern aber daran, dass eine Negativliste (also alle Zeichen die man entfernen möchte) erwarten – ziemlich unpraktisch bei UTF8. Ein regulärer Ausdruck könnte auch helfen, ist aber (auch mit Hinblick auf die Performance) mit Kanonen auf Spatzen geschossen.

Die Kombination aus zwei Translate Befehlen arbeitet mit einer Positivliste. Man gibt also eine Liste erlaubter Zeichen an.

Im folgenden Beispiel soll aus einer Strassenangabe nur der Hausnummernanteil gefiltert werden. Die Positivliste sind hier die Zahlen von 0-9.

 
 with input as 
 (
 select 'Hauptstrasse 35a' hausnummer from dual
 )
 select translate(hausnummer,'x'||translate(hausnummer,'0123456789','X'),'x') from input
 --ergibt : 35
 

Hier der Link zu einer Demo.

Veröffentlicht unter Oracle | Kommentare deaktiviert für Oracle SQL: ungewollte Zeichen aus einem String entfernen

SQLAlchemy: Joined Table Inheritance

Eigentlich lässt die Dokumentation des ORM SQLAlchemy für Python keine Wünsche offen. Auch das Klassenmapping mit Polymorphy ist gut dokumentiert. Was aber noch etwas zu kurz kommt ist die Datenbanksicht.

Ich möchte hier das Beispiel der Dokumentation aufgreifen.
Von einer Basisklasse „Employee“ werden zwei weitere Klassen „Manager“ und „Engineer“ abgeleitet.

Grundsätzlich gibt es verschiedene Strategien Klassenhirarchien abzubilden

  • Joined Table Inheritance:
    Bei dieser Variante gibt es für jede Klasse eine eigene Tabelle. Die beiden Subklassen erhalten eigene Tabellen mit Referenzen auf die Basisklasse.
  • Single Table Inheritance:
    In dieser Form wird die ganze Klassenhierarchie in einer einzelnen Tabelle abgebildet. Aus Blick des Python Codes ist alles sauber. In der Datenbank gibt es aber in der Tabelle Felder, die nur abhängig vom Typ befüllt werden dürfen. Echte Datenbank-Constraints sind damit fast unmöglich.
  • Concrete Table Inheritance:
    Hier gibt es auch wieder für jede Klasse eine Tabelle. Diesesmal haben die Subklassen aber keine Foreign Key Beziehung mit der Basisklasse. Jede Tabelle dupliziert auch die Spalten der Basisklasse. Aus Sicht der Datenbank gibt es nun keine Zentrale Tabelle mehr in der alle „Employees“ erfasst sind. Es lässt sich damit auch kein Foreign Key Constraint mehr setzen.

Um ein sauberes Datenbankmodell zu erhalten, ist somit nur die „Joined Table Inheritance“ zu empfehlen:

  • Auf Spaltenebene können ohne Problem Check-Constraints und Not-Null-Constraints definiert werden.
  • Auch ohne die Kenntnis des SQLALchemy Mappings ergibt sich für andere Anwendungen ganz automatisch welche Felder für welche Klasse gefüllt werden können.
  • Die Basisklasse kann durch andere Tabellen via Foreign Key Constraint referenziert werden.

Wie wird nun eine Joined Table Inheritance in Python gemappt?

class Employee(Base):
    __tablename__ = 'employee'
    Id = Column(Integer
                , primary_key=True)
    Name = Column(String(50))

class Manager(Employee):
    __tablename__ = 'manager'
    Id = Column(Integer
                , ForeignKey(Employee.Id)
                , primary_key=True)
    ManagerStatus = Column(String(50))

    __mapper_args__ = {
        'polymorphic_identity': 'manager',
    }

class Engineer(Employee):
    __tablename__ = 'engineer'
    Id = Column(Integer
                , ForeignKey(Employee.Id)
                , primary_key=True)

    EngineerDegree= Column(String(50))

    __mapper_args__ = {
        'polymorphic_identity': 'engineer',
    }

Daraus lassen sich diese Create-Statements generieren.

create_engine('sqlite:///', echo= True)
Base.metadata.create_all(bind=engine)

CREATE TABLE employee (
	"Id" INTEGER NOT NULL, 
	"Name" VARCHAR(50), --Felder der Basisklasse sind hier  ...
	PRIMARY KEY ("Id")
);
-- und werden in den abgeleiteten Tabelle nicht mehr wiederholt
CREATE TABLE engineer (
	"Id" INTEGER NOT NULL, 
	"EngineerDegree" VARCHAR(50), 
	PRIMARY KEY (id), 
	FOREIGN KEY(id) REFERENCES employee ("Id")
);

CREATE TABLE manager (
	"Id" INTEGER NOT NULL, 
	"ManagerStatus" VARCHAR(50), 
	PRIMARY KEY (id), 
	FOREIGN KEY(id) REFERENCES employee ("Id")
);

Wichtig ist dabei der Fremdschlüssel in den abgeleiteten Klassen, der auf die Basisklasse zeigt:

#Employee.Id bezieht sich dabei auf den Klassen/Attributnamen,
#nicht etwa auf Tabellen oder Spaltenbezeichnungen
Id = Column(Integer,ForeignKey(Employee.Id), primary_key=True)

Vergisst man diesen Fremdschlüssel erhält man folgende Meldung:

  Can’t find any foreign key relationships between ‚employee‘ and ‚manager‘.

 

Veröffentlicht unter Programmierung, Python | Verschlagwortet mit , , , , | Kommentare deaktiviert für SQLAlchemy: Joined Table Inheritance

Datenschutz für kleine Unternehmen – Handreichung

Das Thema Datenschutz betrifft jedes Unternehmen, egal ob groß oder klein. Aber gerade in kleineren Unternehmen scheint das Thema unüberwindbar und wird gar nicht erst angegangen.

Das Bayrische Landesamt für Datenschutzaufsicht hat auf ihrer Website eine Todo-Liste speziell für einzelne Branchen online gestellt.

https://www.lda.bayern.de/de/kleine-unternehmen.html

 

 

Veröffentlicht unter Security | Kommentare deaktiviert für Datenschutz für kleine Unternehmen – Handreichung

GIT-Cheatsheet

Wer bereits mit den Grundsätzen der Versionsverwaltung in SVN vertraut ist, wird sich auch in GIT schnell zurecht finden. Einer der Hauptunterschiede ist, dass nun jeder zur Working-Copy auch noch das komplette Repository lokal hält.

Änderungen am Code werden also erst an das lokale Repository und dann an ein entferntes verteilt. Deswegen sind auch die Begrifflichkeiten für SVN-Umsteiger erst verwirrend.

Wichtige GIT-Begriffe im Schnellcheck:

Weiterlesen

Veröffentlicht unter Allgemein | Verschlagwortet mit , , , , | Kommentare deaktiviert für GIT-Cheatsheet

Regular Expressions und Top Level Domains

Eine häufige Aufgabe in der Programmierung ist das suchen/validieren von Email-Adressen. Mal davon abgesehen, dass ein regulärer Ausdruck nur bedingt dazu benutzt werden kann, funktionieren filtern grobe Näherungen schon mal die meisten.  Weiterlesen

Veröffentlicht unter Programmierung | Verschlagwortet mit , , , , , | Kommentare deaktiviert für Regular Expressions und Top Level Domains

Oracle SQLCL Export in UTF8 mit BOM

Der Export von Daten mit SQLCL funktioniert ähnlich wie beim Großvater SQLPlus.

Leider bietet SQLCL keine Option mit welcher Kodierung die Ausgabe erfolgt. Das lässt sich mit JAVA_TOOL_OPTIONS einstellen. Weiterlesen

Veröffentlicht unter Oracle | Verschlagwortet mit , , , , , , , | Kommentare deaktiviert für Oracle SQLCL Export in UTF8 mit BOM