Опять Кэш

[Eldar9x]

В validateWrite на форме InventTable:

    if (!InventTable.RecId && InventTable::exist(inventTable.ItemId))
        return checkFailed(strfmt("@SYS58214", inventTable.ItemId));

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

правильно ли будет, если я заменю этот участок кода следущим?
(то есть данные тянутся с сервера, а не клиента)

    if (!InventTable.RecId && InventTable::tmn_exist(inventTable.ItemId))
        return checkFailed(strfmt("@SYS58214", inventTable.ItemId));

     tmn_exist():

static server boolean tmn_exist(ItemId  itemId)
{
    InventTable inventTable;
    ;

    flush inventTable;

    select inventTable
        index hint ItemIdx
        where inventTable.itemId == itemId;

    return itemId && inventTable.recId;
}

[ivas]

if (!InventTable.RecId && InventTable::exist(inventTable.ItemId))

замените на

if (InventTable::exist(inventTable.ItemId))

[Владимир Максимов]

А отменить кеширование таблицы InventTable нельзя? CacheLookup = None

[Eldar9x]

ivas, не совсем понимаю, как это мне должно помочь....
Владимир Максимов, этим действием я не получу себе еще больше проблем?

[glibs]

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

Я в таких подлых случаях пишу

inventTable.disableCache(true);

Впрочем, как лучше — не знаю.

Eldar9x, а какая у вас проблема, если не секрет? А то я сталкиваюсь с проблемой, когда в InventTableModule регулярно появляются записи, которых нет в InventTable. Пока не словил причину. Но тоже склонен грешить на кэш.

[Eldar9x]

Цитата:

А то я сталкиваюсь с проблемой, когда в InventTableModule регулярно появляются записи, которых нет в InventTable.

и это тоже, кстати. И еще в других связанных таблицах. Чистил руками в итоге. Точно пока сказать не могу, как это происходит. Вроде как, при сохранении записи, если одно из обязательных полей связанной таблицы не заполнено.
Вообще проблемы начались, когда разрешили удалять записи в таблице номенклатур.
И вообще, я не понимаю, для чего это проверка там вставлена? В inventTable есть уникальный индекс по ItemId, зачем еще этот код?

[ZVV]

Цитата:

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

и это тоже, кстати. И еще в других связанных таблицах. Чистил руками в итоге. Точно пока сказать не могу, как это происходит. Вроде как, при сохранении записи, если одно из обязательных полей связанной таблицы не заполнено.
Вообще проблемы начались, когда разрешили удалять записи в таблице номенклатур.
И вообще, я не понимаю, для чего это проверка там вставлена? В inventTable есть уникальный индекс по ItemId, зачем еще этот код?

Да, действительно как-то глупо...
Думаю можно этот код убрать.
Либо как вариант заменить

if (InventTable::exist(inventTable.ItemId))

на

ttsBegin;
if (InventTable::find(inventTable.ItemId, true))
{...}
ttsCommit;

[Владимир Максимов]

Цитата:

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

Владимир Максимов, этим действием я не получу себе еще больше проблем?

Как указал glibs кеширование влияет на производительность. Но здесь нет однозначного ответа.

По умолчанию, у InventTable режим кеширования Found. Т.е. кешируются только те записи, к которым было обращение (поиск). Следовательно, этот режим кеширования имеет смысл оставить, если каждый пользователь работает в основном с небольшим набором номенклатуры. Или сам справочник номенклатуры небольшой.

Если же большинство пользователей работает со всей картотекой номенклатуры, то нет никакого смысла в кешировании.

У нас кеширование InventTable отключено. Справочник порядка 50 тысяч позиций. Проблем нет. Хотя, удаление записей запрещено

Цитата:

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

И вообще, я не понимаю, для чего это проверка там вставлена? В inventTable есть уникальный индекс по ItemId, зачем еще этот код?

Вопрос момента проверки на уникальность.

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

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

[glibs]

Цитата:

Сообщение от Владимир Максимов

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

Вы заблуждаетесь. Для "Found" кешировнаие будет работать всякий раз, когда в коде вызывается

InventTable::find(...)

А точнее, когда запись выбирается по первичному ключу.

Если код работает на сервере приложений, то в таком случае будет лишнее обращение на сервер БД. Номенклатура там скорее всего будет тоже в кеше, поэтому потери производительности вы можете не ощутить визуально. Впрочем, если запускается долгоиграющая периодическая процедура (типа закрытия склада), в которой может очень-очень много раз вызываться InventTable::find(...) подразумевая, что кеширование включено, производительность может просесть заметно. Не говоря уже о лишнем трафике (Аксапта имеет привычку выбирать все поля в записи).

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

Когда я был помоложе, то тоже увлекался отключением кеширования. Но все-таки пришел к тому, что не стоит.

Вот вам джоб.

static void glibs(Args _args)
{
    InventTable             inventTable;
    Counter                 i;
    TimeOfDay               startTime,
                            endTime;
    ;

    startTime = timenow();
    for (i = 1; i <= 10000; i++)
    {
        inventTable = InventTable::find("Test");
    }
    endTime = timenow();

    info (strfmt("%1", endTime - startTime));

}

Попробуйте позапускать его на тестовой базе с реальным объемом данных при включенном и отключенном кешировании. Заодно еще загрузку сети посмотрите ради любопытства. Код номенклатуры только подставьте реальный.

У меня разница приблизительно на порядок получилась.

[Eldar9x]

Цитата:

Вопрос момента проверки на уникальность.

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

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

Теперь понятно, спасибо за объяснение.

Цитата:

Хотя, удаление записей запрещено

Хм, а что если пользователь создал запись неверно, и есть поля, которые можно редактировать только при создании записи, как решили этот вопрос (у нас только из-за этого и пришлось разрешить удалять записи)?

Цитата:

У меня разница приблизительно на порядок получилась

мда как то не радует. Думаю, тогда и на самом деле не стоит трогать кэширование, тем более что у нас еженочные операции по всей inventTable

[Владимир Максимов]

Цитата:

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

Хм, а что если пользователь создал запись неверно, и есть поля, которые можно редактировать только при создании записи, как решили этот вопрос (у нас только из-за этого и пришлось разрешить удалять записи)?

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

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

[Владимир Максимов]

glibs

Я же говорю, нет однозначного ответа. Зависит от конкретной ситуации и надо смотреть "по месту" что выгоднее: возможная потеря производительности или актуальность данных.

Для нас критичным оказалась именно актуальность данных. Почему? Это уже отдельный вопрос.

По сути, единственное место, где реально ощутима потеря производительности - это display-методы.

Коды циклических процедур все-таки не настолько "тупые", чтобы многократно делать поиск внутри цикла. А если настолько, то на этот случай и нужны программисты, чтобы это исправить

Можно ведь сделать и "закат солнца вручную". В смысле, скидывать найденные записи во временную таблицу внутри цикла. Своеобразный локальный кеш получится.

Насчет закрытия склада - не понял. Где там многократное обращение к одной и той же записи InventTable? Там же единственный цикл именно по InventTable, а потом выбранная запись передается как параметр. Нет повторного InventTable::find()