про «признак необходимости принудительного кэширования»
мне кажется, что для упрощения концепта можно выкинуть этот признак из обсуждения. Просто предполагать, что где-то рядом с «кэшем планов запросов», «кэшем статистики» и прочими есть еще и интеллектуальный-кэш-данных. И можно отдельно обсуждать как его настраивать, какие свойства должен иметь этот кэш и прочее.
разные запросы — это плохо. это снова ошибки при разработке.
С другой стороны, в статье есть запрос «Обороты в разрезе номенклатур и партнеров»
где идет запрос наименований номенклатуры и партнера
const invent = await db.get(line.invent)
const partner = await db.get(doc.partner)
если аналогичный код находится не в отчете, а в методе печати документа (предположим, Расходая накладная)
что делать, если напечатали документ и выяснили, что в наименовании ошибка?
другим документом наименование исправили.
как перепечатать документ с новым наименованием?
отменять-переразносить? с перерасчетом и перерезервированием? но новая разноска может и не выполниться из-за проверок.
кроме того, переразноска все равно должна взять старые реквизиты в некоторых местах (название компании, директор, кассир и прочее)
А если в этих реквизитах тоже были валидные исправления?
в общем, приходим к извечному вопросу учетных систем: как отличить исправления и измененения :)
в этом случае придется делать два набора запросов — один в момент разноски документа, другой для повторного запроса в уже созданном документе. например, вам нужно распечатать документ (для определенности, ПКО) в момент разноски, а также потом в любой момент. Какая фамилия кассира должна появится в распечатке?
.
Спасибо. Спасибо за классную статью. Прежде всего за идею «справочник — это тоже документ». Похоже идею можно развить «в учетной системе все — это документ».
концепт — хорош. «справочник — это документ» — блестяще.
.
что хотелось бы уточнить:
gettop должен получать top на момент документа, которому нужна выборка. Чтобы выборка всегда давала одинаковый результат при разных запросах.
.
но так становится уж слишком похоже на пресловую Точку Актуальности (ТА) в 1С.
распараллелить выполнение, говоря программистским языком.
мне кажется, что для упрощения концепта можно выкинуть этот признак из обсуждения. Просто предполагать, что где-то рядом с «кэшем планов запросов», «кэшем статистики» и прочими есть еще и интеллектуальный-кэш-данных. И можно отдельно обсуждать как его настраивать, какие свойства должен иметь этот кэш и прочее.
С другой стороны, в статье есть запрос «Обороты в разрезе номенклатур и партнеров»
где идет запрос наименований номенклатуры и партнера
const invent = await db.get(line.invent)
const partner = await db.get(doc.partner)
если аналогичный код находится не в отчете, а в методе печати документа (предположим, Расходая накладная)
что делать, если напечатали документ и выяснили, что в наименовании ошибка?
другим документом наименование исправили.
как перепечатать документ с новым наименованием?
отменять-переразносить? с перерасчетом и перерезервированием? но новая разноска может и не выполниться из-за проверок.
кроме того, переразноска все равно должна взять старые реквизиты в некоторых местах (название компании, директор, кассир и прочее)
А если в этих реквизитах тоже были валидные исправления?
в общем, приходим к извечному вопросу учетных систем: как отличить исправления и измененения :)
.
Спасибо. Спасибо за классную статью. Прежде всего за идею «справочник — это тоже документ». Похоже идею можно развить «в учетной системе все — это документ».
.
что хотелось бы уточнить:
gettop должен получать top на момент документа, которому нужна выборка. Чтобы выборка всегда давала одинаковый результат при разных запросах.
.
но так становится уж слишком похоже на пресловую Точку Актуальности (ТА) в 1С.