nicht angemeldet
Hi!
Auch kann es ja sein, dass ich konzeptionell was falsch mache, oder zumindest nicht zu 100% richtig, wodurch das problem von vornherein ausgeschlossen wird.
Du könntest auf Nested Sets umsteigen, dann brauchst du keine Pfadangabe extra zu pflegen, hast vielfältige Abfragemöglichkeiten, musst aber beim Ändern aufpassen (atomare Vorgänge erstellen (Sperren setzen und/oder Transaktionen verwenden)). Dokumentationen und beispielhafte Abfragen dazu lassen sich einige finden.
Ich wüsst jetzt nicht was an meinem Herangehen verwerflich sei, aber wenn du meinst hier wäre alles gesagt, dann schließe ich mich deiner Meinung an.
Ich denke, das hat auch was mit beobachten und schlussfolgern zu tun. Und ich fragt auch nach deinen Gedankengängen, was du dir so vorstellen kannst, wie man noch zwei Werte tauschen kann.
Es hat sich ja schon gezeigt, dass SQLite es nicht einmal vorübergehend mag, wenn man einen Unique Constraint verletzt. Also kann es keine Lösungen geben, die eine solche Verletzung vornehmen. Wenn doch, muss es ein Fehler sein, denn das bedeutete inkonsistentes Verhalten, was den Unique Constraint angeht. Ich würde mich nicht auf solches Verhalten verlassen wollen oder darauf spekulieren, dass es in späteren Versionen Bestand hat. Also bleiben nur Lösungen, die den Unique Constraint vorübergehend deaktivieren oder ihn nicht verletzen. Und da gibt es nichts weiter außer den genannte Methoden. Das Tauschen von zwei Werten geht nur über einen dritten oder wenn man beide gleichzeitig ändert, was aber eben hier nicht mit einem UPDATE geht, weil bei den beiden impliziten Teilvorgängen eben die Verletzung stattfindet. Bleibt noch beide zu entfernen und geändert nacheinander wieder einzusetzen (oder mit einem Multi-Insert).
Lo!