- Verschifft
- 19. August 2026 um 08:09 UTC
- Autor
- Kamo
- Ausschuss
- 2d0a998
Vier Endpunkte der wieder aufgebauten Wissensbasis benötigt, und drei Fakten der API war unfähig zu erklären. GET /api/kb/pins zurückgegeben eine Seite von Pin ROWS, und KbArticlePin.article ist @JsonIgnore - so die Antwort trug eine Pin-ID, ein Mitglied id und ein Datum, und nichts darüber, welcher Artikel gepinnt worden war. Die Homepage hat darum gebeten Liste, da es ausgeliefert und gemacht nichts, weil eine Seite Umschlag hat keine .Länge und die Wache vor dem Abschnitt war eine Länge Überprüfung. Pinning hat nie arbeitete Ende zu Ende. Es gibt jetzt die Artikel selbst zurück, gelöst innerhalb einer Transaktion, anstatt sich auf Open-in-View zu lehnen. GET /api/kb/articles/overview ist neu: Status zählt, jeder Artikel ist real Daten, Autorschaft, Wortzahl und Auszug, plus die angehefteten Guride des Anrufers, in man liest. Die Homepage verwendet, um "jüngste" zu fälschen, indem Sie die ersten zehn Knoten von der Baum und Stempel sie mit einem leeren Datum. GET /api/kb/reviews/queue ist neu: was wartet und was vor kurzem war abgewickelt, beide Hälften in einer Anfrage. Ein Rezensent, der auf eine leere Warteschlange schaut, fragt die gleiche Frage so oder so - ist nichts Warten, oder habe ich nur klar. Seine entschiedene Lektüre ist eine LIST mit einer Grenze, nicht eine Seite: innerhalb der lesbaren Transaktion einer Seite verworfen COUNT ist nie Aussage #1, so Yugabyte kann nicht Starten Sie es neu und ein gleichzeitiges Schreiben verwandelt die Warteschlange in eine 40001. GET /api/kb/media sendet jetzt die Artikelauszählung jeder Zeile und für die Typen ein Raster zeichnet, seine vorsignierte URL. Die Zählung wurde immer nur von der Single-Ressource Endpunkt, so dass die Bibliothek "in N-Artikel" Warnung vor ein Lösch könnte nie feuern - ein Diagramm eingebettet in neun Artikel als gelöscht ruhig wie ein Waisenkind. Die URLs waren eine Anfrage pro Miniaturbild nach der Liste war schon gelandet. POST /api/kb/media/urls Zeichen eine Charge für Anrufer, die halten Sie schon Reihen. Jede int64 Mitglieds-ID geht als STRING. Sie sind 19-stellige unique_rowid() Werte und eine JSON-Nummer ist ein IEEE-Double im Browser - die Einsender-ID auf der Überprüfung Warteschlange kam vor gerundet, weshalb es nie sein konnte abgestimmt gegen das Mitglied Verzeichnis und eine rohe ID saß, wo ein Name hingehört. Keine Shared-Bibliotheksänderung, also kein KamoInitializer-Lauf und keine Flotten-Umschichtung.