# Was ist der beste Weg, Daten mit einem Plugin zu speichern?

**URL:** https://meta.discourse.org/t/whats-the-best-way-to-store-data-with-a-plugin/388967
**Category:** Development
**Created:** [19. November 2025 um 07:27 UTC](https://meta.discourse.org/t/whats-the-best-way-to-store-data-with-a-plugin/388967 "2025-11-19T07:27:04Z")
**Posts on this page:** 13
**Page:** 1

<div class="post-metadata">

### Author: ![NateDhaliwal](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/natedhaliwal/32/313494_2.png) [@NateDhaliwal](https://meta.discourse.org/u/NateDhaliwal)
#### Post date: [19. November 2025 um 07:27 UTC](https://meta.discourse.org/t/whats-the-best-way-to-store-data-with-a-plugin/388967/1 "2025-11-19T07:27:04Z")

</div>

Ich plane, Daten mit einem Plugin zu speichern, nämlich genau einen Wert, eine Topic-ID. Was ist der beste Weg, dies zu tun?

Danke.

---

<div class="post-metadata">

### Author: ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [19. November 2025 um 08:04 UTC](https://meta.discourse.org/t/whats-the-best-way-to-store-data-with-a-plugin/388967/2 "2025-11-19T08:04:18Z")

</div>

Wenn Sie nur eine einzelne Topic-ID speichern müssen (wie einen konfigurierbaren Wert), ist der einfachste Discourse-native Weg die Verwendung einer `SiteSetting`.  
Sie erhalten außerdem automatisch eine integrierte Admin-Benutzeroberfläche.

`config/settings.yml`:

```yml
plugins:
  my_plugin_enabled:
    default: true
    client: false

  my_plugin_topic_id:
    default: 0
    client: false
    type: topic # erstellt einen Themenwähler in der Admin-Benutzeroberfläche

```

In Ihrem Ruby-Plugin-Code:

```rb
topic_id = SiteSetting.my_plugin_topic_id
topic = Topic.find_by(id: topic_id)

```

Wenn Sie es vorziehen, es programmatisch zu speichern (nicht als Einstellung verfügbar gemacht), ist `PluginStore` ebenfalls für ein einzelnes Schlüssel-Wert-Paar geeignet:

```rb
store = PluginStore.new("my_plugin")
store.set("topic_id", some_topic_id)

topic_id = store.get("topic_id")

```

---

<div class="post-metadata">

### Author: ![NateDhaliwal](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/natedhaliwal/32/313494_2.png) [@NateDhaliwal](https://meta.discourse.org/u/NateDhaliwal)
#### Post date: [19. November 2025 um 08:07 UTC](https://meta.discourse.org/t/whats-the-best-way-to-store-data-with-a-plugin/388967/3 "2025-11-19T08:07:15Z")

</div>

Ich denke, der PluginStore ist der am besten geeignete Weg. Eine Website-Einstellung passt nicht zu diesem Anwendungsfall. Danke!

---

<div class="post-metadata">

### Author: ![Moin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/moin/32/554653_2.png) [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [19. November 2025 um 08:30 UTC](https://meta.discourse.org/t/whats-the-best-way-to-store-data-with-a-plugin/388967/4 "2025-11-19T08:30:51Z")

</div>

Ihre Frage erinnerte mich an etwas, das ich kürzlich auf Meta gelesen habe.

> [@blake](#):
>
> „Gibt es Themen, die davon handeln, den PluginStore nicht mehr zu verwenden? Ich versuche herauszufinden, ob ich den PluginStore verwenden oder einfach meine eigene Datenbanktabelle und Spalten in einem Plugin erstellen soll, an dem ich arbeite“, antwortete der Discourse AI Bot mit einer hilfreichen Antwort und verlinkte sogar direkt zu unserem Entwicklungsstilhandbuch, in dem genau beschrieben wird, was ich verwenden sollte.
> 
> ![](https://global.discourse-cdn.com/meta/original/4X/f/f/4/ff461f0e5d8ce1349dcf0d34bd012f5edd1cf8bb.png)

---

<div class="post-metadata">

### Author: ![NateDhaliwal](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/natedhaliwal/32/313494_2.png) [@NateDhaliwal](https://meta.discourse.org/u/NateDhaliwal)
#### Post date: [19. November 2025 um 08:32 UTC](https://meta.discourse.org/t/whats-the-best-way-to-store-data-with-a-plugin/388967/5 "2025-11-19T08:32:39Z")

</div>

Ich wollte gerade anfangen – danke, dass Sie das zur Sprache gebracht haben. Es scheint, als wäre eine ganze Datenbanktabelle für 1 Wert übertrieben und völlig unnötig. Irgendwelche Ideen?

---

<div class="post-metadata">

### Author: ![Moin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/moin/32/554653_2.png) [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [19. November 2025 um 08:42 UTC](https://meta.discourse.org/t/whats-the-best-way-to-store-data-with-a-plugin/388967/6 "2025-11-19T08:42:06Z")

</div>

Was ist der Grund, warum Sie keine Website-Einstellung wünschen? Sie könnte verborgen werden, sodass Administratoren sie nicht sehen, ähnlich wie die IDs für die speziellen Themen im Kern, wie z. B. TOS.

> <https://github.com/discourse/discourse/blob/908d590fe30a132e48d90d1a2c961236c408a911/config/site_settings.yml#L3619>

---

<div class="post-metadata">

### Author: ![NateDhaliwal](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/natedhaliwal/32/313494_2.png) [@NateDhaliwal](https://meta.discourse.org/u/NateDhaliwal)
#### Post date: [19. November 2025 um 08:45 UTC](https://meta.discourse.org/t/whats-the-best-way-to-store-data-with-a-plugin/388967/7 "2025-11-19T08:45:44Z")

</div>

Mein Anwendungsfall ist folgender: Jedes Thema oder jeder Beitrag, der mit dem Plugin erstellt wird, wird synchronisiert und an anderer Stelle gespeichert. Themen, die davor erstellt wurden, werden dies jedoch nicht, daher muss ich einen Job ausführen, um diese zu synchronisieren, vielleicht in Stapeln von 100. Ich muss die niedrigste Themen-ID speichern, damit der nächste Stapel diese minus 100 ist und so weiter.

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [19. November 2025 um 09:20 UTC](https://meta.discourse.org/t/whats-the-best-way-to-store-data-with-a-plugin/388967/8 "2025-11-19T09:20:55Z")

</div>

Der Chatbot macht etwas sehr Ähnliches.

Hier ist die Migration:

> <https://github.com/merefield/discourse-chatbot/blob/main/db/migrate/20240217010103_create_chatbot_post_embeddings_bookmark_table.rb>

---

<div class="post-metadata">

### Author: ![NateDhaliwal](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/natedhaliwal/32/313494_2.png) [@NateDhaliwal](https://meta.discourse.org/u/NateDhaliwal)
#### Post date: [19. November 2025 um 09:58 UTC](https://meta.discourse.org/t/whats-the-best-way-to-store-data-with-a-plugin/388967/9 "2025-11-19T09:58:16Z")

</div>

Das ist gut – zumindest bin ich nicht der Einzige 😆… meine nächste Hürde ist, wie ich die Migration ausführe – in einer Dev-Discourse-Seite oder etwas anderem… würde die Ausführung der Migration dann nicht einfach zum _Discourse_-Migrationsverzeichnis hinzugefügt werden? Soll ich die Datei manuell kopieren? Danke.

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [19. November 2025 um 10:35 UTC](https://meta.discourse.org/t/whats-the-best-way-to-store-data-with-a-plugin/388967/10 "2025-11-19T10:35:19Z")

</div>

Sie platzieren es, wie bei allen Plugin-Migrationen, im Plugin (genau wie beim Chatbot oben).

Sie führen Migrationen mit `LOAD_PLUGINS=1 rake db:migrate` aus

Lesen Sie hier mehr über Migrationen:

> **[Active Record Migrations — Ruby on Rails Guides](https://guides.rubyonrails.org/active_record_migrations.html)**
>
> Migrations are a feature of Active Record that allows you to evolve your database schema over time. Rather than write schema modifications in pure SQL, migrations allow you to use a Ruby Domain Specific Language (DSL) to describe changes to your...

---

<div class="post-metadata">

### Author: ![NateDhaliwal](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/natedhaliwal/32/313494_2.png) [@NateDhaliwal](https://meta.discourse.org/u/NateDhaliwal)
#### Post date: [19. November 2025 um 10:47 UTC](https://meta.discourse.org/t/whats-the-best-way-to-store-data-with-a-plugin/388967/11 "2025-11-19T10:47:18Z")

</div>

Ich verstehe nur nicht, dass ich die Minute und Sekunde manuell eingeben soll, wenn ich die Datei erstelle?

---

<div class="post-metadata">

### Author: ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [19. November 2025 um 11:24 UTC](https://meta.discourse.org/t/whats-the-best-way-to-store-data-with-a-plugin/388967/12 "2025-11-19T11:24:00Z")

</div>

Lesen Sie die Anleitung. Nicht überzeugt, dass Sie sie über Abschnitt 1 hinaus gelesen haben. 😉

---

<div class="post-metadata">

### Author: ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)
#### Post date: [20. November 2025 um 07:15 UTC](https://meta.discourse.org/t/whats-the-best-way-to-store-data-with-a-plugin/388967/13 "2025-11-20T07:15:23Z")

</div>

> [@NateDhaliwal](#):
>
> Ich denke, der PluginStore ist der am besten geeignete Weg. Eine Site-Einstellung passt nicht zu diesem Anwendungsfall. Danke!

Ich denke, wir sollten den PluginStore wahrscheinlich veraltet machen, cc @david, er führt auf lange Sicht nur zu Problemen.

Das Erstellen neuer Tabellen und Modelle ist meiner Meinung nach der richtige Weg.

> [@NateDhaliwal](#):
>
> Mein Anwendungsfall ist dieser: Jedes Thema oder jeder Beitrag, der erstellt wird, sobald das Plugin aktiviert ist, wird synchronisiert und an anderer Stelle gespeichert. Themen davor jedoch nicht, daher muss ich einen Job ausführen, um diese zu synchronisieren, vielleicht in Stapeln von 100. Ich muss die niedrigste Themen-ID speichern, damit der nächste Stapel diese minus 100 ist und so weiter.

Post- und Themen-Benutzerfelder können dafür funktionieren. Der Nachteil ist jedoch, dass die Indizierung schwierig sein kann, da es sich nicht richtig anfühlt, Indizes zu Kerntabellen hinzuzufügen. Das führt uns zurück zur Einführung neuer Tabellen.
