Die Datei components/DataTable.vue ist wie folgt aufgebaut:

<template>
  <div v-if="posts">
    <v-data-table
        v-model:items-per-page="itemsPerPage"
        :headers="headers"
        :items="posts"
        item-value="userId"
        class="elevation-1"
    ></v-data-table>
  </div>
</template>
<script>
import { ref } from 'vue'
import getAllPosts from '../services/getAllPosts'
export default {
  setup() {
    const { posts, error, load } = getAllPosts()
    const itemsPerPage = ref(10)
    load()
    return {
      posts,
      error,
      itemsPerPage,
      headers: [
        { title: 'User Id', align: 'start', key: 'userId' },
        { title: 'Title', align: 'start', sortable: false, key: 'title' },
        { title: 'Body', align: 'start', sortable: false, key: 'body' },
      ],
    }
  },
}
</script>

Die Datei services/getAllPosts.js ist folgendermaßen aufgebaut:

import { ref } from 'vue'
import axios from 'axios'
const getAllPosts = () => {
  const posts = ref(null)
  const error = ref(null)
  const load = async () => {
    try {
      const { data } = await axios.get('https://jsonplaceholder.typicode.com/posts'
)
      console.log(data)
      posts.value = data
      console.log(posts.value)
    } catch (err) {
      console.log(err)
      error.value = err.message
    }
  }
  return { posts, error, load }
}
export default getAllPosts

Welche Aussagen stimmen?

Was ist Serverseitiges Rendering (SSR) in Vue.js und warum würde man es verwenden?

SSR bedeutet, dass die Vue.js-Anwendung auf dem Server gerendert und als vollständig gerenderte HTML-Seite an den Browser gesendet wird. Man verwendet es, um:

• Die initiale Ladezeit zu verbessern: Der Benutzer sieht sofort Inhalt, bevor das JavaScript geladen und interaktiv wird.
• SEO zu verbessern: Suchmaschinen-Crawler können den Inhalt der Seite besser indexieren, da sie vollständiges HTML erhalten. Frameworks wie Nuxt.js sind darauf spezialisiert, SSR für Vue-Anwendungen einfach zu machen.

Die Datei App.vue ist folgendermaßen definiert:

<template>
  <v-app>
    <v-app-bar color="primary" dark>
      <v-app-bar-title>Data Table</v-app-bar-title>
      <v-spacer></v-spacer>
      <v-switch
          v-model="isDark"
          hide-details
          inset
          :label="isDark ? 'Dark' : 'Light'"
          class="ma-2"
      ></v-switch>
    </v-app-bar>
    <v-main>
      <DataTable />
    </v-main>
  </v-app>
</template>
<script>
import { ref, watch } from 'vue'
import { useTheme } from 'vuetify'
import DataTable from './components/DataTable.vue'
export default {
  name: 'App',
  components: { DataTable },
  setup() {
    const theme = useTheme()
    const isDark = ref(false)
    watch(isDark, (newValue) => {
      theme.global.name.value = newValue ? 'dark' : 'light'
    })
    return {
      isDark,
    }
  },
}
</script>

Welche Aussagen stimmen?

@Entity(name = "Contact")
public static class Contact {
    @Id
    private Integer id;
    private Name name;
    private String notes;
    private URL website;
    private boolean starred;
    //Getters and setters are omitted for brevity
}
@Embeddable
public class Name {
    private String firstName;
    private String middleName;
    private String lastName;
    // getters and setters omitted
}

Entities, by nature of their unique identifier, exist independently of other objects whereas values do not. Entities are domain model classes which correlate to rows in a database table, using a unique identifier. Because of the requirement for a unique identifier, entities exist independently and define their own lifecycle. The Contact class itself would be an example of an entity.

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);
}

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?

Das CAP-Theorem besagt: Ein verteiltes System kann alle der drei folgenden Eigenschaften vollständig und gleichzeitig 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.