обновление поля в заданной таблице

[Eldar9x]

В диалоге вводится tableName. Для указанной таблицы, то есть в ней, есть поле TMN_ImportStatus. Дальше по нажатию ok происходит обновление этого поля.
Таблица, в которой происходит обновление поля, становится известна только при запуске кода. Как это провернуть с использованием Common? Query использовать нехочется, на крайний случай map.

То есть вот чего хочу:

    TableName tableName;
    Common  common;
    ;

    ttsbegin;

    while select forupdate common
    {
        common.(fieldname2id(tablename2id(tableName), "TMN_ImportStatus")) = 100;
        common.doUpdate();
    }

    ttscommit;

как указать, какая таблица будет в common?

[oip]

static void Job279(Args _args)
{
    common c;
    FieldId fieldId;
;
    c = new DictTable(tableNum(InventTable)).makeRecord();
    fieldId = fieldName2Id(tableNum(InventTable), 'ItemId');
    while select c
    {
       info (c.(fieldId));
    }
}

Только всякие проверки еще надо бы добавить, естественно. На тип поля, на то, что оно вообще существует и.т.д.

[gl00mie]

Цитата:

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

То есть вот чего хочу:

    TableName tableName;
    Common  common;
    ;
    ttsbegin;
    while select forupdate common
    {
        common.(fieldname2id(tablename2id(tableName), "TMN_ImportStatus")) = 100;
        common.doUpdate();
    }
    ttscommit;

как указать, какая таблица будет в common?

Хотя технически это достижимо, но тут в угоду некой универсальности и простоте реализации приносится в жертву смысл выполняемых действий, реализуемая бизнес-логика (то, что mazzy называет "программистский подход"). Во-первых, обвновление по doUpdate() смотрится странно, потому что обход триггера обновления на таблице имеет смысл, если вы абсолютно точно знаете, что делаете, а если даже неизвестно, какая именно таблица будет обновляться, то, очевидно, это условие в общем случае не выполняется. Подумайте о том, что реализуемый функционал и, соотв., список используемых таблиц будет расширяться - появятся таблицы, о которых вы сейчас и не подозреваете, а разработчики, расширяющие функционал, весьма вероятно, не будут подозревать о наличии такого "каверзного" кода. Весьма вероятно, изменение TMN_ImportStatus на той или иной таблице должно будет сопровождаться дополнительными действиями, которые нельзя предвидеть заранее.
Мне кажется, было бы корректнее реализовать некую иерархию классов-обработчиков этого изменения, каждый из которых мог бы создаваться под свою конкретную таблицу (в любом случае изначально на все существующие таблицы может быть один-единственный класс), и в любом случае жестко зашить весь список таблиц, о которых вы сейчас знаете:

static TMN_ImportStatusUpdater_Base construct(TableId _tableId)
{
    TMN_ImportStatusUpdater_Base    ret;
    ;
    switch(_tableId)
    {
        case tablenum(TMN_Table1) :
        case tablenum(TMN_Table2) :
        case tablenum(TMN_Table3) :
            ret = new TMN_ImportStatusUpdater_Base();
            break;
        default :
            throw error(error::wrongUseOfFunction(funcname()));
    }
    ret.parmTableId( _tableId );
    return ret;
}

// ...
tableId     = dfTableId.value();
newStatus   = dfStatus.value();
TMN_ImportStatusUpdater_Base::construct( tableId ).updateImportStatus( newStatus );

[oip]

Цитата:

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

...

В общем случае - согласен. Но в каком-то конкретном, такое решение через common может и иметь смысл, надо на постановку задачи смотреть. Если это функция, типа "очистить все" в каком-нибудь функционале, расположенном сбоку, то why not?

Там в "поблагодарить..." текст левый случайно попал, рука дрогнула. Не обращайте внимание.

[Eldar9x]

Цитата:

Хотя технически это достижимо, но тут в угоду некой универсальности и простоте реализации приносится в жертву смысл выполняемых действий, реализуемая бизнес-логика (то, что mazzy называет "программистский подход").

никоим образом.

Цитата:

Во-первых, обвновление по doUpdate() смотрится странно, потому что обход триггера обновления на таблице имеет смысл, если вы абсолютно точно знаете, что делаете

именно поэтому - doUpdate

смысл реализуемого процесса: установить содержимое таблицы, в стартовое состояние до начала импорта.
В момент импорта (в котором, кстати, и реализован тот паттерн, который вы описали ниже), происходит переустановка значений этого поля в зависимости от того, что происходит со строкой, изменяется, создается, пропускается или вообще, вручную, создается пользователем.
Зачем? Просто для того, чтобы сравнить содержимое таблицы до и после импорта. Плюс текстовый лог изменений. Программерская паранойя, что тут скажешь...

[gl00mie]

Цитата:

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

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

Не знаю, по каким причинам у вас в таблицах могут быть "пустые" записи, созданные до иморта, но по-хорошему вашу хотелку надо реализовать в методе initValue() соотв. таблиц(ы), ну и не забывать дергать этот метод при импорте. Еще не забудьте про такой функционал, как шаблоны записей. В initValue() шаблон подпихивается при вызове super(), так что это следует учесть при реализации вашего кода (т.е. вызывать ли super() в initValue() до или после вашего кода).

[Eldar9x]

Цитата:

надо на постановку задачи смотреть.

нет ее , сейчас я ставлю себе задачи сам.

Цитата:

Если это функция, типа "очистить все", то why not?

оно и есть.

[Eldar9x]

в initValue() как раз и записывается значение "Создано пользователем". При создании строки импортом, оно переписывается значением "Создано".