- Verschifft
- 16. August 2026 um 01:13 UTC
- Autor
- Kamo
- Ausschuss
- 3cc8b30
Spring Data leitet eine zweite Anweisung für jede Seite, die es zurückgibt, und der Chat Geschichte gelesen für eine fragte es nie an: MediaController nimmt page.getContent() und meldet dann messages.size() als Zählzahl. Die abgeleiteten Erklärung war SELECT COUNT(m1_0.id) VON media_objs m1_0 LEFT JOIN media_objs_msg m3_0 ON m1_0.id = m3_0.obj_id WO m1_0.session_id = ? UND m1_0.is_removed = false ein nicht indexiertes Aggregat über jedes Objekt in der Sitzung, ausgestellt nach dem Transaktion hatte bereits gelesen, das ist genau die Form, die YugabyteDB nicht kann von. Es kann nur transparent neu starten eine Lektüre, die die FIRST ist Anweisung in der Transaktion; ein späteres wirft SQLState 40001 "Neustart lesen erforderlich", ist die Transaktion nur Rollback-und nur markiert, und die Anfrage 500s. So ein Öffnen Sie Chat-Fenster, das zufällig nachladen, während jemand schrieb auf die gleiche Sitzung zeigte keine Geschichte überhaupt, wegen einer Anzahl, die weggeworfen wurde. Die Zeilen kommen jetzt als Liste zurück, die keine Zählung ausgibt. Gleiche Abfrage, gleiche Bestellung, gleiche Seite; eine Anweisung statt zwei. Die Page-Returning-Methode bleibt für MediaStreamController, die wirklich serviert ************ zum Social Feed. Jeder zweite Anrufer nahm .getContent() und warf die Summe weg, so dass die beiden Public-Chat Websites bewegen sich auch über (MediaService, separaten Commit).