|
Странный результат последовательности delete + update
|
|||
---|---|---|---|
#18+
Наткнулся на странное поведение при последовательных delete и update в одной транзакции. Есть табличка с деревом и 2мя порядками для детей: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
В порядках не должно быть дырок. Вот один из наборов детей: Код: sql 1. 2. 3. 4.
ID PARENT_ID ORD_NUM_EN ORD_NUM_RU 653027 470108 1 1 653026 470108 2 2 653025 470108 3 3 653024 470108 4 4 653023 470108 5 5 653022 470108 6 10 653021 470108 7 13 653020 470108 8 17 470109 470108 9 19 653019 470108 10 9 653018 470108 11 11 470110 470108 12 6 470111 470108 13 7 653017 470108 14 12 653016 470108 15 18 470113 470108 16 14 653015 470108 17 15 653014 470108 18 16 470114 470108 19 8 Одна из операций - удаление детей по некоторому условию. Если условие выполняется, строка удаляется, а у остальных корректируется порядки. Вся операция происходит в одной транзакции. (псевдокод): Код: python 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
В результате порядки получаются несколько странные: ID PARENT_ID ORD_NUM_EN ORD_NUM_RU 470109 470108 5 11 470110 470108 6 3 470111 470108 7 4 470113 470108 8 9 470114 470108 10 4 Если идти по детям в обратном порядке ( order by ORD_NUM_EN desc ), то ORD_NUM_EN получается правильный, а ORD_NUM_RU - какой попало... Кто-нибудь может объяснить такое странное поведение? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2015, 13:08 |
|
Странный результат последовательности delete + update
|
|||
---|---|---|---|
#18+
Забыл указать. Пакет: firebird2.5-super Версия: 2.5.2.26540.ds4-9ubuntu1 ОС Код: plaintext 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2015, 13:17 |
|
Странный результат последовательности delete + update
|
|||
---|---|---|---|
#18+
TonalВерсия: 2.5.2.26540Видимо, это всё относится к http://tracker.firebirdsql.org/browse/CORE-3362 (курсор видит свои же изменения). ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2015, 13:22 |
|
Странный результат последовательности delete + update
|
|||
---|---|---|---|
#18+
Таблоид, вряд ли. Это же не на стороне сервера происходит. Питон наверняка материализует результаты выборки. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2015, 13:30 |
|
Странный результат последовательности delete + update
|
|||
---|---|---|---|
#18+
Симонов Денис, +1 насчет материализации. Tonal, Я бы эти три запроса вывел в отдельную процедуру и из клиента делал только Код: python 1. 2.
чтобы исключить "неестественный интеллект" (© DS) промежуточных слоев доступа к базе данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2015, 13:48 |
|
Странный результат последовательности delete + update
|
|||
---|---|---|---|
#18+
Для проверки сделал execute block , аналогичный приведённому коду на python: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
Результат его выполнения совпадает с результатом скрипта. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2015, 14:03 |
|
Странный результат последовательности delete + update
|
|||
---|---|---|---|
#18+
Т. е. похоже именно CORE-3362 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2015, 14:05 |
|
Странный результат последовательности delete + update
|
|||
---|---|---|---|
#18+
Tonal, Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
так попробуй. Хотя я пока никак не въеду что ты тут собираешься сделать. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2015, 14:07 |
|
Странный результат последовательности delete + update
|
|||
---|---|---|---|
#18+
Tonalorder by r.ORD_NUM Замени на "order by r.ORD_NUM+0". Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2015, 14:07 |
|
Странный результат последовательности delete + update
|
|||
---|---|---|---|
#18+
Симонов Денися пока никак не въеду что ты тут собираешься сделать. Бездырочную нумерацию он делает. Проктостоматолог, что с него возьмёшь... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2015, 14:17 |
|
Странный результат последовательности delete + update
|
|||
---|---|---|---|
#18+
В общем дошло - сам дурак. :) Значения ORD_NUM-ов берутся старые, до того как начали отрабатывать delete/update. Чтобы заработало как задумано нужны актуальные. т. е. их нужно перезапрашивать. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
Ну а на Python-е я вовсе по другому сделал - собрал всех оставшихся в список, отсортировал как надь и восстановил нумерацию. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2015, 14:58 |
|
Странный результат последовательности delete + update
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovБездырочную нумерацию он делает. Проктостоматолог, что с него возьмёшь... Поддерживаю. Когда-то было такое дурное решение принято. Теперь смысла нет всё переделывать... ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2015, 15:00 |
|
Странный результат последовательности delete + update
|
|||
---|---|---|---|
#18+
Не столько ответ, сколько для истории TonalЗначения ORD_NUM-ов берутся старые, до того как начали отрабатывать delete/update. Чтобы заработало как задумано нужны актуальные. т. е. их нужно перезапрашивать. Эта проблема была бы замечена если в исходном сообщении был бы пример лямбды mast_del, который не передаёт конкретный id, а передаёт условие cid > ... Можно и по данным догадаться, но я вот, например, попался :) На Питон грешить тут действительно нечего, потому как при Код: python 1.
выборка полностью фетчится и материализуется (особенности списочных выражений в Питоне, сам драйвер так и делает при fetchall). TonalНу а на Python-е я вовсе по другому сделал - собрал всех оставшихся в список, отсортировал как надь и восстановил нумерацию. Я не знаю природы данных и их распределения для таких запросов, но может получится, что будет много апдейтов уже "приговорённых" записей, подпадающих под условие. Может лучше сделать процедуру ..._renumerate(id), которая в 2 прохода перенумерует записи. Для FB3.0 можно будет писать так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2015, 16:13 |
|
|
start [/forum/topic.php?fid=40&fpage=75&tid=1562802]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
44ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
97ms |
get tp. blocked users: |
2ms |
others: | 272ms |
total: | 455ms |
0 / 0 |