delete_from

[chel]

Добрый день

Сталкивался ли кто-нибудь со следующей проблемой в delete_from:

Если на таблицу, по которой делается delete_from, навешан delete action, то не выполняется операция delete на СУБД, а выполняется select и потом delete по одной строке (точь в точь как описано в DevGuide в случае переопределенного метода delete() на таблице)

Можно ли как-нибудь обойти эту проблему или шансов нет?

База Oracle

Заранее спасибо.

[Yprit]

skipDeleteActions(), по-моему...

[chel]

Но сделать, чтобы delete actions также отработали, и запрос выполнился как delete, шансов нет?

Т.е. делаем вывод, что delete actions не задаются на уровне СУБД, а остаются на уровне приложения?

[mazzy]

да.

[chel]

Цитата:

Изначально опубликовано mazzy
да.

Спасибо. Буду думать, как ускорить...

[Nikolaich]

А в чем проблема - вы хотите чтобы DeleteActions вообще не отрабатывали или хотите
чтобы отрабатывали но как-то быстрее ?

[chel]

Да, хотелось бы быстрее.
Наверняка cascade на СУБД выполняется быстрее, чем select/delete по одной записи в приложении.

[George Nordic]

Хм. Только триггер на таблице в базе...

Но это не есть хорошо...
В частности, Ваш приемние может так и никогда и не узнать о подобной "барабашке"

С Уважением,
Георгий.

[simply2double]

Цитата:

Изначально опубликовано George Nordic
Хм. Только триггер на таблице в базе...

Но это не есть хорошо...
В частности, Ваш приемние может так и никогда и не узнать о подобной "барабашке"

С Уважением,
Георгий.

Не советую так поступать... в случае с аксаптой номера с тригерами СУБД не прокатывают.
Сталкивался стакой проблемой, которую так и не смог ни преодолеть, ни объяснить вразумительно. Если время исполнеия тригера СУБД значительно, то аксапта считает что операция не смогла успешно закончиться и откатывает транзакцию... при этом в интерфейсе фиксируется нормально завершенная операция. Хотя при рефреше интерфейса, все возвращается на круги своя...
Предположили, что проблема впланировщике, который определяет некий тайминг для исполнения, и когда его ожидания не оправдываются, он констатирует откат транзакции... Возможно что и не так...
Так что решайте все проблемы средствами аксапты... целее будете..

[chel]

Цитата:

Изначально опубликовано simply2double


Не советую так поступать... в случае с аксаптой номера с тригерами СУБД не прокатывают.
Сталкивался стакой проблемой, которую так и не смог ни преодолеть, ни объяснить вразумительно. Если время исполнеия тригера СУБД значительно, то аксапта считает что операция не смогла успешно закончиться и откатывает транзакцию... при этом в интерфейсе фиксируется нормально завершенная операция. Хотя при рефреше интерфейса, все возвращается на круги своя...
Предположили, что проблема впланировщике, который определяет некий тайминг для исполнения, и когда его ожидания не оправдываются, он констатирует откат транзакции... Возможно что и не так...
Так что решайте все проблемы средствами аксапты... целее будете..

Ценная информация, спасибо. Хотя я вроде и не собирался решать проблему вне системы. Думал над отключением relation'a и его ручным эмулированием (благо операция удаления может выполняться только в очень небольшом количестве мест)

[Vadik]

PHP код:

ttsbegin;

delete_from detailTable 
exists join masterTable where masterTable...;

delete_from  masterTable;

ttscommit; 


DeleteActions все равно отработают, но физическое удаление из DetailTable пройдет за одну операцию

[Nikolaich]

exists join существенно медленнее inner, посмотрите на трассировку запросов
- там на сервер посылается подзапрос where exists (то есть тот же select).

[Vadik]

Цитата:

Изначально опубликовано Nikolaich
exists join существенно медленнее inner, посмотрите на трассировку запросов
- там на сервер посылается подзапрос where exists (то есть тот же select).

В трассировку смотрел. Насчет "существенно" несогласен

Я тут примерчик набросал. Посмотрите плана исполнения. Убедитесь, что наличие WHERE EXISTS() в запросе совсем не означает обязательного его (подзапроса) исполнения для каждой удаляемой строки. Люди, которые сиквелу оптимизатор пишут, тоже незря хлеб едят

PHP код:

set showplan_all on
go

begin tran

delete trans
from bmssa.LedgerTrans trans
inner join bmssa.LedgerTable ledger on ledger.AccountNum = trans.AccountNum 
where ledger.dataareaid = 'dmo' and trans.DataAreaId = 'dmo' and ledger.AccountNum = '    01.000'

rollback
go

begin tran

delete trans
from bmssa.LedgerTrans trans
where trans.DataAreaId = 'dmo' and exists
    (select * 
    from bmssa.LedgerTable ledger 
    where 
        ledger.DataAreaid = 'dmo' and 
        ledger.AccountNum = trans.AccountNum and
        ledger.AccountNum = '    01.000')

rollback tran
go 


[chel]

Цитата:

Изначально опубликовано Vadik

PHP код:

ttsbegin;

delete_from detailTable 
exists join masterTable where masterTable...;

delete_from  masterTable;

ttscommit; 


DeleteActions все равно отработают, но физическое удаление из DetailTable пройдет за одну операцию

Да, решение конечно элегантное, но рождает какие-то странные проблемы. Выполнение такого запроса скатывается в full scan по detailTable, хотя индекс по внешнему ключу есть. Есть подозрение, что это происходит в результате большого количества удаляемых записей.

[Vadik]

Цитата:

Изначально опубликовано chel
Выполнение такого запроса скатывается в full scan по detailTable, хотя индекс по внешнему ключу есть. Есть подозрение, что это происходит в результате большого количества удаляемых записей.

Скорее всего. Так получается, если затрагивается более 5 - 10 (цифра приблизительная) процентов записей.

- если просто удаляется единичная запись из masterTable, можно упростить до delete_from detailTable where detailTable.Key = masterTable.Key и сравнить планы
- наконец, можно "вправить мозг" оптимизатору хинтом

Жаль, что не работает

PHP код:

delete_from detailTable
join masterTable 


[chel]

Цитата:

Изначально опубликовано Vadik


Скорее всего. Так получается, если затрагивается более 5 - 10 (цифра приблизительная) процентов записей.

- если просто удаляется единичная запись из masterTable, можно упростить до delete_from detailTable where detailTable.Key = masterTable.Key и сравнить планы
- наконец, можно "вправить мозг" оптимизатору хинтом

Жаль, что не работает

PHP код:

delete_from detailTable
join masterTable 


К сожалению, удаление именно большого количества строк - порядка тысяч. А код delete...join... - просто мечта . Ладно, пока придется оставить как есть.
Большое спасибо за советы.