Много документов: пересчитать вычисляемые поля

dimat

Lotus team
31.07.2008
516
0
#1
Всем привет!
В представлении отображается порядка 7 тысяч документов, в них во всех необходимо пересчитать вычисляемые поля.
Делаю цикл по этим документам и каждому делаю:

Код:
Call NotesDocument.ComputeWithForm(False,False)
Call NotesDocument.Save(True,False)
Есть ли какие то более быстрые способы, реализации данной задачи?

Заранее спасибо за ответы!
 

ToxaRat

Чёрный маг
Lotus team
06.11.2007
3 231
18
#2
а как же - не использовать ComputeWithForm
сделать вычисления всех нужных полей самому, даже если это будут все поля в доке всё равно будет быстрее чем ComputeWithForm
 

Medevic

Что это ? :)
Lotus team
10.12.2004
3 346
1
#3
@Command([ToolsRefreshAllDocs])

Добавлено: Вариант: @Command([ToolsRefreshSelectedDocs])
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 586
272
#5
UI команды не работают в бэкэнде...

а воще - подойти к вопросу творчески... :ya_lamo:
ведь вычисляемые поля берут данные откуда-то, и не всегда каждое вычисление уникально (чаще всего - не уникально)
вычислять поля для опред условий и копировать результат в соответ доки

Добавлено: либо вынести вычисления в отдельный блок кода и вызывать его по мере надобности
 

dimat

Lotus team
31.07.2008
516
0
#6
Еще одна проблема: при выполнения на документами
Код:
Call NotesDocument.ComputeWithForm(False,False)
Call NotesDocument.Save(True,False)
не приводит к ожидаемому результату, то есть flag=true, но поля остаются не пересчитанными.

В чем может быть проблема?
 
O

oshmianski

#7
ComputeWithForm очень коварная штука.
перевычисление полей происходит в порядке расположения полей на форме слева направо, сверху вниз.
при возникновении ошибки перевычисления поля дальнейшее перевычисления документа прерывается.

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

Omh

Lotus team
04.07.2007
2 210
1
#8
А ещё лучше вообще не кодировать логику приложения на уровне полей, а всё вынести в функции (только не использовать как входные параметры всякие там UI).
Вызываем ф-ию на QuerySave (ну или по желанию на recalc, если надо) - всё пересчиталось.
Надо обработать кучу док-ов, вызываем эту же ф-ию из агента.

Всё, геморррой отпал как класс.

А да, ComputeWithForm - в печь!
 

dimat

Lotus team
31.07.2008
516
0
#9
в моем случае значение поля в одном документе зависит от значиния поля в другом.
Пример: есть документ организации в нем поле "тип" (принимает значения клиент или пусто).
так же есть дкумент продукт (в нем поле со значениями "на обслуживании" или "в отказе" ), этих продуктов у организации может быть несколько. Необходимо вычислать значение поля в документе Организации по следущему правилу: Если хотя бы в одном документе продукта значение поля="На обслуживании"- то клиент, иначе пусто
 

Omh

Lotus team
04.07.2007
2 210
1
#10
dimat
Мне, честно говоря, лень вдаваться в подробности, но я не видел такой формульной логики, которую бы нельзя было перенести на скрипт.
В отличие от обратного :blush:

Да, иногда получается чуть медленне (и то это почти всегда решаемо: static переменные, подумать иногда можно), но зато приобретается централицация кода + гибкость вызова когда и где надо.

У тебя, наверно, там стоит какой-то либо @DbLookup, как я понял из описания.
Это меняется на получение view (достаточно медленная операция, тут можно поиграться со static) и проверки по ключу.
 

dimat

Lotus team
31.07.2008
516
0
#11
У тебя, наверно, там стоит какой-то либо @DbLookup, как я понял из описания.
Да
Это меняется на получение view (достаточно медленная операция, тут можно поиграться со static) и проверки по ключу.
не понял что имеется ввиду
 

nvyush

Lotus team
22.04.2009
2 317
0
#12

Omh

Lotus team
04.07.2007
2 210
1
#13
не понял что имеется ввиду
Если обощить, то имеется в виду, что надо избавляться от логики на уровне полей и писать логику в биб-ках.

Т.е. @DbLookup в choices у DialogBox - это нормально и правильно.
Но всякие сложные формулы у computed полей, inpit validation, input translation и т.д. нафик выносить в скрипт.
Насчёт input translation можно подискутировать, иногда там удобно что-то быстро преобразовать, но делать проверку обязательных полей на inpit validation - сразу руки под корень :)
То же самое относится и к каким-либо расчётам на формулах - это же пипец потом в поддержке.
 

ToxaRat

Чёрный маг
Lotus team
06.11.2007
3 231
18
#14
ComputeWithForm очень коварная штука.
перевычисление полей происходит в порядке расположения полей на форме слева направо, сверху вниз.
при возникновении ошибки перевычисления поля дальнейшее перевычисления документа прерывается.
забыл сказать самое главное :)
если вычисления собираются в какое-то временное CFD поле и потом из него берётся в обычные поля то ComputeWithForm тут не поможет, так как CFD поля он не расчитывает и все формулы зависящие от них тоже слетают ;)
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 586
272
#15
как и положено CFD и работают тока в UI :)
 

dimat

Lotus team
31.07.2008
516
0
#16
Если обощить, то имеется в виду, что надо избавляться от логики на уровне полей и писать логику в биб-ках.

Т.е. @DbLookup в choices у DialogBox - это нормально и правильно.
Но всякие сложные формулы у computed полей, inpit validation, input translation и т.д. нафик выносить в скрипт.
Насчёт input translation можно подискутировать, иногда там удобно что-то быстро преобразовать, но делать проверку обязательных полей на inpit validation - сразу руки под корень smile.gif
То же самое относится и к каким-либо расчётам на формулах - это же пипец потом в поддержке.
То есть правильней будет заменить вычисляемые поля на скрипт в квери сейв? я правильно понял?
 
O

oshmianski

#17
у меня каждому (ну или почти каждому) объекту базы (читай форме) соответствует самописный класс, который наследуется от базового самописного суперкласса. в суперклассе описана логика уровня приложения, в наследуемых классах описана логика, специфичная для данного объета. в этих двух классах перегружены все ui методы формы, и только они дергаются в форме.
кроме того, очень полезно разделять ui и background логику. и чем больше получится в backgound, тем лучше.

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

Omh

Lotus team
04.07.2007
2 210
1
#18
dimat
Если уверен в том, что можешь безошибочно перенвести @Formula -> LS, то да.

Правильнее будет логику (скрипт) вынести в ф-ию которую ты сам будешь вызывать, где надо.
В первую очередь, конечно, на QS формы, быть может тебе ещё понадобится на QRC.
+ в том злополучном агенте, из-за которого началась заварушка.

Я бы оформил это дело примерно так

<!--shcode--><pre><code class='vb'>Function Calc_Logic_By_Dimat(doc as notesdocument) as boolean
Exit Function[/CODE]

Т.е. ф-ия получающая на входе NotesDocument и возвращающая True только в том случае, если в результате пересчёта помеялось значение какого-либо поля.

Тогда потом в твоём агенте будет удобно:
<!--shcode--><pre><code class='vb'>Dim session As New NotesSession

Dim Agent As NotesAgent
Set Agent = Session.CurrentAgent

Dim Db As NotesDatabase
Set Db = Agent.Parent

Dim Query As String
Query = {Form = "Тра-ля-ля"}

Dim Coll As NotesDocumentCollection
Set Coll = Db.Search(Query, Nothing, 0)

Set Doc = Coll.GetFirstDocument
While Not Doc Is Nothing
if Calc_Logic_By_Dimat(Doc) then Call Doc.Save(True, False)
Set Doc = Coll.GetNextDocument(Doc)
Wend
End If[/CODE]

Я обычно использую примерно такой подход.
 

Omh

Lotus team
04.07.2007
2 210
1
#20
oshmianski
Ну то что там написано болдом - сущая правда: "для изменения информации (т.е. для реализации бизнес-логики) всегда и везде использовать скрипт!"

Правда, я классы использую только там, где (imho) действительно нужно: напрмер word обернуть в класс, ну или что-то в этом роде.
Мне обычно для бизнес логики хватает функционального подхода, т.е. всё делается в ф-иях.
Всё-таки 6-7 лотус не очень, кмк, подходит для классов - вылазит вся убогость встроенного дизайнера :)

Судя по микро-срачу в комментариях, не только я так думаю ;)

Хотя, статья хорошая несомненно.