Folgende application.properties ist gegeben:

venlab.datasource.jdbc-url=jdbc:postgresql://172.19.2.15:5432/venlab?currentSchema=venlab
venlab.datasource.password=mustImportantChangeHere
venlab.datasource.username=postgres
venlab.datasource.platform=postgresql
jpa.properties.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
jpa.properties.hibernate.jdbc.lob.non_contextual_creation=true
jpa.hibernate.ddl-auto=none
jpa.generate-ddl=false
jpa.show-sql=false

Ist diese ausreichend, um sich auf die Datenbank über Spring-Boot zu verbinden?

Welche Aussagen stimmen über diesen Sourcecode!

import venlab.at.data.model.Box;
import org.springframework.data.domain.Page;
import org.springframework.data.domain.Pageable;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.jpa.repository.JpaSpecificationExecutor;
import org.springframework.data.jpa.repository.Query;
import java.util.Optional;
public interface BoxRepository extends JpaRepository<Box, String>, JpaSpecificationExecutor<Box> {
    Optional<Box> findBybId(String bId);
    @Query("from Box b")
    Page<Box> findAllByQuery(Pageable paging);
}

Wofuer steht das Kürzel REST?

Heutzutage werden NoSQL-Datenbanken anhand der beiden von ihnen unterstützten CAP-Merkmale klassifiziert:

Das CAP-Theorem besagt: Ein verteiltes System kann nicht gleichzeitig alle drei folgenden Eigenschaften vollständig garantieren:

1. Consistency (Konsistenz) – Jeder Knoten sieht zu jeder Zeit den gleichen Datenstand. Das heißt: Nach einer Datenänderung sind alle Kopien überall direkt aktualisiert.
2. Availability (Verfügbarkeit) – Jede Anfrage an das System wird (auch bei Ausfällen einzelner Knoten) beantwortet, das System ist also stets funktionsfähig.
3. Partition Tolerance (Partitionstoleranz) – Das System funktioniert auch dann weiter, wenn die Kommunikation zwischen Bestandteilen (also Knoten) gestört ist. Es „toleriert“ also Netzausfälle oder Partitionen.

Stellen wir uns vor, ein System ist partitioniert (Es gibt eine Netzwerkunterbrechung):

• Willst du Konsistenz? Dann musst du Anfragen möglicherweise ablehnen, solange du keinen synchronisierten Stand gewährleisten kannst (d.h. die Verfügbarkeit leidet).
• Willst du Verfügbarkeit? Dann akzeptierst du, dass in Partitionen die Daten temporär inkonsistent sein können.

Der SQL- Standard definiert vier Ebenen der Transaktionsisolation. Am strengsten ist Serializable, das im Standard in einem Absatz definiert wird, der besagt, dass jede gleichzeitige Ausführung einer Reihe serialisierbarer Transaktionen garantiert den gleichen Effekt hat, als würden sie einzeln in einer bestimmten Reihenfolge ausgeführt.

Die anderen drei Ebenen (Read uncommitted, Read committed, Repeatable read) werden anhand von Phänomenen (Dirty Read, Nonrepeatable Read, Phantom Read) definiert, die sich aus der Interaktion zwischen gleichzeitigen Transaktionen ergeben und nicht auf jeder Ebene auftreten dürfen. Der Standard stellt fest, dass aufgrund der Definition von Serializable keines dieser Phänomene auf dieser Ebene möglich ist.

Folgendes docker-compose.yml ist gegeben:

services:
  postgres:
    image: postgres:13
    container_name: postgres-backup
    restart: always
    env_file:
      - login.env
    ports:
      - "5432:5432"
    volumes:
      - ./postgres:/var/lib/postgresql/data
    networks:
      backend:
        ipv4_address: 192.168.1.100
  adminer:
    image: adminer
    container_name: adminer
    restart: always
    ports:
      - "8080:8080"
    depends_on:
      - postgres
    networks:
      backend:
        ipv4_address: 192.168.1.101
networks:
  backend:
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.1.0/24

Ist diese Konfiguration lauffähig?

In der restore.sql wird ein Schema venlab erstellt.

Folgende Antworten sind richtig in Bezug auf das Schema: