DQL steht für Data Query Language und ist ein Teil der SQL-Sprache (Structured Query Language). Sie dient dazu, Daten aus einer Datenbank abzufragen, ohne sie zu verändern.

Hauptmerkmal von DQL:

• Nur lesend: Mit DQL werden Daten abgefragt, aber nicht eingefügt, verändert oder gelöscht.

• Der zentral verwendete Befehl ist:

SELECT

Beispiel:

SELECT name, geburtsdatum FROM kunden WHERE stadt = 'Berlin';

Dieser Befehl liest die Namen und Geburtsdaten aller Kunden aus, die in Berlin wohnen – verändert aber nichts an den Daten.

DQL im Vergleich zu anderen SQL-Teilen:

Ein Entity Manager ist ein zentraler Bestandteil von ORM-Frameworks (Object-Relational Mapping), vor allem im Zusammenhang mit Java (JPA – Java Persistence API), aber auch in anderen Sprachen wie PHP (Doctrine ORM).

Hier ist eine verständliche Erklärung:

💡 Definition:

Ein Entity Manager ist eine Komponente, die sich um die Verwaltung von Datenbank-Entities (also Objekten/Datensätzen) kümmert. Er bildet die Schnittstelle zwischen der objektorientierten Welt des Codes und der relationalen Welt der Datenbank.

📦 Aufgaben eines Entity Managers:

1. Persistieren (Speichern):

   • Speichert ein neues Objekt (Entity) in der Datenbank.

   • Beispiel: $entityManager->persist($user);

2. Finden/Laden:

   • Holt ein Objekt anhand seiner ID oder anderer Kriterien.

   • Beispiel: $entityManager->find(User::class, 1);

3. Aktualisieren:

   • Änderungen an einem Objekt werden verfolgt und in die Datenbank geschrieben (z. B. beim flush()).

4. Entfernen/Löschen:

   • Löscht ein Objekt aus der Datenbank.

   • Beispiel: $entityManager->remove($user);

5. Transaktionen verwalten:

   • Beginnt, commitet oder rollt Transaktionen zurück.

6. Query-Handling:

   • Führt eigene Abfragen aus, oft mit DQL (Doctrine Query Language) oder JPQL.

🔁 Lebenszyklus von Entities:

Der Entity Manager verwaltet den „Zustand“ von Objekten:

• managed (verfolgt Änderungen),

• detached (nicht mehr verwaltet),

• removed (zum Löschen markiert),

• new (noch nicht gespeichert).

🛠 Beispiel mit Doctrine (PHP):

$user = new User();
$user->setName('Max Mustermann');

$entityManager->persist($user); // Zum Speichern vormerken
$entityManager->flush();        // Tatsächlich in DB schreiben

Fazit:

Der Entity Manager ist der zentrale Ansprechpartner, wenn es darum geht, mit Datenbankobjekten zu arbeiten – lesen, schreiben, ändern, löschen. Er abstrahiert die SQL-Ebene und macht die Datenbankarbeit objektorientiert steuerbar.

Doctrine DBAL (Database Abstraction Layer) ist eine PHP-Bibliothek, die eine Abstraktionsschicht für den Datenbankzugriff bietet. Sie ist ein Teil von Doctrine, einem weit verbreiteten ORM-Projekt (Object-Relational Mapping), aber kann unabhängig vom ORM verwendet werden.

Ziel und Nutzen von Doctrine DBAL:

Doctrine DBAL bietet eine einheitliche API, um mit verschiedenen Datenbanken (wie MySQL, PostgreSQL, SQLite usw.) zu kommunizieren, ohne direkt SQL für die jeweilige Datenbank schreiben zu müssen.

Hauptfunktionen von Doctrine DBAL:

• Verbindungsverwaltung:

• • Verbindungsaufbau zu Datenbanken über Konfigurationsarrays.

  • Unterstützung für Verbindungs-Pooling, Transaktionen usw.

• SQL-Query-Builder:

• • Dynamisches Erstellen von SQL-Abfragen über eine objektorientierte API:

$qb = $conn->createQueryBuilder();
$qb->select('u.id', 'u.name')
   ->from('users', 'u')
   ->where('u.age > :age')
   ->setParameter('age', 18);
$stmt = $qb->executeQuery();

• Datenbankunabhängigkeit:

  • Die gleichen Funktionen und Abfragen funktionieren mit verschiedenen DBMS, z. B. MySQL, PostgreSQL, SQLite.

• Schema-Management:

  • Werkzeuge zum Erstellen, Ändern und Vergleichen von Datenbankschemata.

  • Nützlich für Migrationen.

• Datentyp-Konvertierung:

  • Konvertiert Daten zwischen PHP und dem nativen Datenbankformat.

use Doctrine\DBAL\DriverManager;

$conn = DriverManager::getConnection([
    'dbname' => 'test',
    'user' => 'root',
    'password' => '',
    'host' => 'localhost',
    'driver' => 'pdo_mysql',
]);

$result = $conn->fetchAllAssociative('SELECT * FROM users');

Wann DBAL statt ORM?

Du verwendest DBAL ohne ORM, wenn:

• Du mehr Kontrolle über SQL willst.

• Dein Projekt keine komplexe Objekt-Mapping-Logik braucht.

• Du bereits vorhandene SQL-Strukturen nutzen musst.

Fazit:

Doctrine DBAL ist ein mächtiges Werkzeug für sauberen, portablen und sicheren Datenbankzugriff in PHP, ohne sich auf ein vollständiges ORM einlassen zu müssen. Es liegt genau zwischen direktem PDO-Zugriff und einem vollwertigen ORM wie Doctrine ORM.

Ein Join Point ist ein Begriff aus der Aspect-Oriented Programming (AOP), also der aspektorientierten Programmierung.

Definition:

Ein Join Point ist eine definierte Stelle im Ablauf eines Programms, an der zusätzlicher Code (ein sogenannter Aspekt) eingefügt werden kann.

Typische Beispiele für Join Points:

• Aufruf einer Methode

• Ausführung einer Methode

• Zugriff auf ein Attribut (lesen oder schreiben)

• Werfen einer Ausnahme

Kontext:

In AOP wird Programmcode modularisiert, indem Querschnittsfunktionen (wie Logging, Sicherheit, Transaktionsmanagement) aus dem eigentlichen Anwendungscode ausgelagert werden. Diese Funktionen werden dann an bestimmten Punkten im Programmablauf (den Join Points) „eingeschnitten“.

Weitere Begriffe im Zusammenhang:

• Pointcut: Eine Ausdrucksweise, mit der beschrieben wird, welche Join Points betroffen sind (z. B. „alle Methoden mit dem Namen save*“).

• Advice: Der Code, der an einem Join Point ausgeführt wird (z. B. „logge diesen Methodenaufruf“).

• Aspect: Eine Kombination aus Pointcut(s) und Advice(s) – also ein vollständiges Modul, das eine Querschnittsfunktion implementiert.

Beispiel (in Spring AOP):

@Before("execution(* com.example.service.*.*(..))")
public void logBeforeMethod(JoinPoint joinPoint) {
    System.out.println("Aufruf von: " + joinPoint.getSignature().getName());
}

→ Hier wird vor jedem Methodenaufruf in einem bestimmten Package ein Logging-Code ausgeführt – und joinPoint.getSignature() liefert Details zum konkreten Join Point.

Aspect-Oriented Programming (AOP) ist ein Programmierparadigma, das sich darauf konzentriert, Querschnittsfunktionen (Cross-Cutting Concerns) modular zu kapseln. Es ergänzt objektorientierte oder funktionale Programmierung, indem es Code, der sich durch viele Klassen oder Module zieht, auslagert und separat behandelt.

💡 Ziel:

Probleme wie Logging, Sicherheitsprüfungen, Fehlerbehandlung, Transaktionsmanagement oder Performance-Messungen sind typische Cross-Cutting Concerns. Diese wiederholen sich oft in vielen Klassen und Methoden – AOP ermöglicht es, solchen Code zentral zu schreiben und automatisch an den richtigen Stellen auszuführen.

🔧 Grundbegriffe:

• Aspect: Ein Modul, das eine Querschnittsfunktion kapselt.

• Advice: Der eigentliche Code, der ausgeführt wird (z. B. vor, nach oder anstatt einer Methode).

• Join Point: Ein Punkt im Programmablauf, an dem ein Aspect eingreifen kann (z. B. Methodenaufruf).

• Pointcut: Eine Definition, welche Join Points betroffen sind (z. B. "alle Methoden in Klasse X").

• Weaving: Der Prozess, bei dem Aspect-Code mit dem eigentlichen Code „verwoben“ wird – zur Laufzeit, beim Kompilieren oder beim Laden.

🛠 Beispiel (in Java mit Spring AOP):

@Aspect
public class LoggingAspect {
    @Before("execution(* com.example.service.*.*(..))")
    public void logBeforeMethod(JoinPoint joinPoint) {
        System.out.println("Methode wird aufgerufen: " + joinPoint.getSignature().getName());
    }
}

Dieser Code führt automatisch Logging aus, bevor jede Methode im com.example.service-Paket ausgeführt wird.

✅ Vorteile:

• Bessere Modularität

• Weniger Code-Duplikate

• Trennung von Fachlogik und Querschnittslogik

❌ Nachteile:

• Kann die Lesbarkeit erschweren (man sieht nicht sofort, was alles beim Methodenaufruf passiert).

• Debugging kann komplexer sein.

• Oft framework-abhängig (z. B. Spring, AspectJ).

Assertions (auf Deutsch: Behauptungen oder Zusicherungen) sind Programmierkonstrukte, mit denen du Annahmen über den Zustand deines Programms überprüfst. Eine Assertion prüft, ob eine bestimmte Bedingung wahr ist – wenn nicht, wird typischerweise ein Fehler ausgelöst und das Programm abgebrochen.

Beispiel (in Python):

x = 10
assert x > 0   # läuft problemlos
assert x < 5   # AssertionError, weil x nicht kleiner als 5 ist

Zweck von Assertions:

• Sie helfen beim Debuggen: Du überprüfst, ob bestimmte Voraussetzungen im Code erfüllt sind.

• Sie dokumentieren implizite Annahmen: z. B. „An dieser Stelle muss die Liste mindestens ein Element haben.“

• Sie dienen der Fehlersuche in der Entwicklungsphase – im Produktivcode werden sie oft deaktiviert.

Wichtiger Unterschied zu regulären Fehlerbehandlungen:

Assertions sollen Programmfehler aufdecken, nicht Benutzereingaben oder äußere Einflüsse abfangen. Beispiel:

• assert age > 0 → falsch, wenn age aus Benutzereingabe stammt.

• Stattdessen: if age <= 0: raise ValueError("Alter muss positiv sein.")

Design by Contract (DbC) ist ein Konzept aus der Softwareentwicklung, das von Bertrand Meyer eingeführt wurde. Es beschreibt eine Methode zur Sicherstellung der Korrektheit und Zuverlässigkeit von Software, indem Verträge zwischen den verschiedenen Komponenten (z.B. Methoden, Klassen) definiert werden.

Grundprinzipien von Design by Contract

Bei DbC wird jede Software-Komponente wie eine Vertragspartei gesehen, die bestimmte Verpflichtungen und Garantien einhält:

1. Vorbedingungen (Preconditions)
   Bedingungen, die erfüllt sein müssen, bevor eine Methode oder Funktion korrekt ausgeführt werden kann.
   → Verantwortung des Aufrufers.

2. Nachbedingungen (Postconditions)
   Bedingungen, die nach der Ausführung garantiert werden.
   → Verantwortung der Methode/Funktion.

3. Invariant (Klasseninvariante)
   Bedingungen, die während der gesamten Lebenszeit eines Objekts wahr bleiben müssen.
   → Verantwortung sowohl der Methode als auch des Aufrufers.

Ziel von Design by Contract

• Klare Spezifikation der Verantwortlichkeiten.

• Robustere und besser testbare Software.

• Fehler werden frühzeitig erkannt (z.B. durch Verletzung des Vertrags).

Beispiel in Pseudocode

class BankAccount {
    private double balance;

    // Invariante: balance >= 0

    void withdraw(double amount) {
        // Vorbedingung: amount > 0 && amount <= balance
        if (amount <= 0 || amount > balance) throw new IllegalArgumentException();

        balance -= amount;

        // Nachbedingung: balance wurde um amount verringert
    }
}

Vorteile

• Klare Verträge führen zu weniger Missverständnissen.

• Bessere Fehlersuche, da Verstöße gegen Verträge sofort auffallen.

• Unterstützt die defensive Programmierung.

Nachteile

• Erhöhter Aufwand in der Spezifikation.

• Nicht von allen Programmiersprachen direkt unterstützt (z.B. Java, C++ über Assertions, Python mit Decorators; Eiffel unterstützt DbC nativ).

Ein Cronjob ist ein geplanter, wiederkehrender Hintergrundprozess auf Unix- oder Linux-basierten Systemen. Er wird vom Dienstprogramm cron ausgeführt, das regelmäßig überprüft, ob Aufgaben (Jobs) laut Zeitplan auszuführen sind.

Merkmale eines Cronjobs:

• Automatisierung: Aufgaben wie Backups, Updates, E-Mail-Versand oder Skript-Ausführungen laufen automatisch.

• Zeitsteuerung: Du legst genau fest, wann und wie oft ein Job ausgeführt werden soll (z. B. täglich um 3:00 Uhr oder jeden Montag).

• Konfiguration: In sogenannten Crontabs (Cron-Tabellen) wird der Zeitplan definiert.

Syntax-Beispiel (in einer Crontab-Datei):

0 3 * * * /usr/bin/php /var/www/mein-skript.php

Bedeutung:

• 0 3 * * * → Jeden Tag um 03:00 Uhr

• /usr/bin/php /var/www/mein-skript.php → Das auszuführende Kommando

Zeitfelder im Überblick:

* * * * *  (Minute Stunde Tag Monat Wochentag)

Vorteile:

• Spart Zeit durch Automatisierung

• Verringert menschliche Fehler

• Ideal für regelmäßige Aufgaben

Ein Daemon (ausgesprochen wie „dä-mon“, nicht wie das englische „demon“) ist ein Hintergrundprozess, der auf einem Computersystem läuft – meist ohne direkte Benutzerinteraktion.

Merkmale eines Daemons:

• Startet automatisch beim Hochfahren des Systems.

• Läuft dauerhaft im Hintergrund.

• Erledigt Aufgaben, ohne dass der Benutzer direkt mit ihm arbeitet.

• Hört auf Anforderungen von anderen Programmen oder Netzwerken.

Beispiele:

• cron-Daemon: Führt zeitgesteuerte Aufgaben aus (z. B. tägliche Backups).

• sshd: Behandelt SSH-Verbindungen von außen.

• httpd oder nginx: Webserver-Dienste.

• cupsd: Druckaufträge verwalten.

Technischer Hintergrund:

• In Unix/Linux endet ein Daemon-Prozessname oft mit „d“ (z. B. httpd, systemd).

• Ein Daemon wird oft beim Systemstart durch Init-Systeme wie systemd oder init gestartet.

Ursprung des Begriffs:

Der Begriff stammt aus der griechischen Mythologie, wo „Daimon“ eine Art Geist oder übernatürliches Wesen war, das im Hintergrund wirkte – passend zur Funktion im Betriebssystem.

Perl Compatible Regular Expressions (PCRE) sind eine Implementierung von regulären Ausdrücken, die sich an der Syntax und Funktionalität der Programmiersprache Perl orientiert. Sie bieten eine sehr mächtige, flexible und erweiterte Syntax, die über einfache reguläre Ausdrücke hinausgeht.

Warum „Perl Compatible“?

Perl war eine der ersten Sprachen, die besonders leistungsstarke reguläre Ausdrücke eingeführt hat. Die PCRE-Bibliothek wurde entwickelt, um diese Funktionen auch in anderen Programmiersprachen und Tools verfügbar zu machen – zum Beispiel in:

• PHP

• Python (teilweise, re-Modul ähnelt PCRE)

• JavaScript (mit leichten Abweichungen)

• grep-Varianten wie pcregrep

• Texteditoren wie VS Code, Sublime Text etc.

Wichtige Features von PCRE:

✅ Lookahead & Lookbehind:

• (?=...) – positive Lookahead

• (?!...) – negative Lookahead

• (?<=...) – positive Lookbehind

• (?<!...) – negative Lookbehind

✅ Nicht-gierige Quantifizierer:

• *?, +?, ??, {m,n}?

✅ Benannte Gruppen:

• (?P<name>...) oder (?<name>...)

✅ Unicode-Support:

• \p{L} für Unicode-Buchstaben usw.

✅ Assertions und Grenzen:

• \b, \B, \A, \Z, \z

✅ Modifikatoren:

• (?i) für case-insensitive

• (?m) für multiline usw.

(?<=\buser\s)\w+

Dieser Ausdruck findet Wörter, die nach "user " stehen (Lookbehind).

Fazit:

PCRE sind die "Deluxe-Version" regulärer Ausdrücke – sie sind leistungsfähig, weit verbreitet und flexibel. Wenn du in einem Tool oder einer Sprache arbeitest, die „PCRE unterstützt“, kannst du dich auf die mächtige Perl-ähnliche Syntax freuen.