Где изменяется статус заказа?

[AvrDen]

Цитата:

Сообщение от pitersky

В вашем случае как раз и подошёл бы способ, предложенный Tasmanian Devil. Напишите метод, который по завершении обработки строк накладной проверяет, можно ли изменить статус заказа.

Да я так и попробую. Посмотрим как это повлияет.

[ice]

Цитата:

Сообщение от AvrDen

Да я так и попробую. Посмотрим как это повлияет.

простое убирание обновления статуса в разноске из цикла в конец отработки всех строк, скорее всего мало повлияет на скороть обработки:
1. это не самая тяжелая операция
2. updateStatus вызывается еще при обновлении строк заказа

[AvrDen]

Цитата:

Сообщение от ice

простое убирание обновления статуса в разноске из цикла в конец отработки всех строк, скорее всего мало повлияет на скороть обработки:
1. это не самая тяжелая операция
2. updateStatus вызывается еще при обновлении строк заказа

При анализе нашли, что больше тормоза происходят в методе salesLine.lowestSalesStatus, который вызываеться из salesTable.updateBackStatus. Скорее всего из-за того что нет индекса по SalesId,SalesStatus в таблице salesLine. В итоге получается что при обработке заказа больше 1000 строк на обработку одной строки уходит порядка 10 сек.

[ice]

Цитата:

Сообщение от AvrDen

При анализе нашли, что больше тормоза происходят в методе salesLine.lowestSalesStatus, который вызываеться из salesTable.updateBackStatus. Скорее всего из-за того что нет индекса по SalesId,SalesStatus в таблице salesLine. В итоге получается что при обработке заказа больше 1000 строк на обработку одной строки уходит порядка 10 сек.

раз так, то добавьте нужный индекс. а лучше включите трассировку sql-запросов и посмотрите, какие конкретно запросы тормозят

[mazzy]

Цитата:

Сообщение от ice

раз так, то добавьте нужный индекс

угу.
а еще лучше - удаляйте старые уже обработанные заказы

при правильном кодировании все параметры из заказа должны переноситься в документы.
при правильном кодировании ни отчеты, ни обработки не должны обращаться к старым заказам
при правильном кодировании обработанные заказы могут автоматически удалятся (см. параметр модуля)
функционал умеет также "сокращать" строки заказа, автоматически убирая уже обработанную часть.

если обработанные заказы удаляются, то на логическом уровне получается красивая картина:
УЖЕ сделанное находится в фактических документах
ОЖИДАЕМОЕ в ближайшем будущем находится в заказах

[pitersky]

Цитата:

Сообщение от mazzy

угу.
а еще лучше - удаляйте старые уже обработанные заказы

При всём уважении к этому подходу - ни разу не видел на внедрениях, чтобы он применялся. Думаю, что бухгалтерия встанет на дыбы, но такого не допустит.

[AvrDen]

Цитата:

Сообщение от mazzy

угу.
а еще лучше - удаляйте старые уже обработанные заказы

У нас это требование руководства - хранить "историю"....

[someOne]

Цитата:

Сообщение от AvrDen

У нас это требование руководства - хранить "историю"....

Не самое лучшее решение...

А вы предлагали альтернативные варианты руководству ?

Чем не устраивает хранение истории обработанных счетов на оплату например ?
Там есть вся необходимая информация по истории заказа.

Не удаляя строки заказов вы неизбежно будете получать тормоза. Со временем будет только хуже.

[AvrDen]

Цитата:

Сообщение от ice

раз так, то добавьте нужный индекс. а лучше включите трассировку sql-запросов и посмотрите, какие конкретно запросы тормозят

Да в трассировке и нашли что тормозит

    select minof(SalesStatus) from salesLine
        where   salesLine.SalesId       == salesId              &&
                salesLine.SalesStatus   >  SalesStatus::None;

[Zabr]

Цитата:

Сообщение от AvrDen

При анализе нашли, что больше тормоза происходят в методе salesLine.lowestSalesStatus, который вызываеться из salesTable.updateBackStatus. Скорее всего из-за того что нет индекса по SalesId,SalesStatus в таблице salesLine. В итоге получается что при обработке заказа больше 1000 строк на обработку одной строки уходит порядка 10 сек.

Не очень понятно, поможет ли индекс, ведь в том запросе второе поле SalesStatus сравнивается не на совпадение, а на "больше". По идее, индекс дает эффект только при условии на равенство... или я не прав ?