Классы LedgerJournalTransEntityManager, LedgerJournalTransEntityInMemRollback, LedgerJournTransEntityFrmDatEventManager

[Logger]

Добрый день всем.

Кто-нибудь разбирал работу классов
LedgerJournalTransEntityManager,
LedgerJournalTransEntityInMemRollback,
LedgerJournTransEntityFrmDatEventManager

?

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

Некоторые места совсем странные.
Например
\Classes\LedgerJournalTransEntityInMemRollback\performRollbackForAbortedDelete

    // The cursor has been changed by the kernel, but the delete was unsuccessful. Re-read the records
    // and point to the correct buffer.
    ledgerJournalTrans_DS.research();
    ledgerJournalTrans_DS.findRecord(ledgerJournalTransSnapshot);

    // Get the cursors
    ledgerJournalTransCursor = ledgerJournalTrans_DS.cursor();

FindRecord() конечно оптимальное решение для поиска строки

или тут :
\Data Dictionary\Tables\LedgerJournalTrans\Methods\copyTo

    // Generate the list of system fields contained by this table.
    systemFieldIds.add(fieldnum(LedgerJournalTrans, RecId));
    systemFieldIds.add(fieldnum(LedgerJournalTrans, RecVersion));
    systemFieldIds.add(fieldnum(LedgerJournalTrans, DataAreaId));

С каких-то пор поля Created*, Modified* перестали быть системными ? Походу автор метода никогда не читал Global::buf2buf() и в глаза не видел Global::isSysId()

В общем, осталось ощущение какого-то набора костылей. Неужели нельзя было без этого обойтись. Ядро в конце концов пофиксить если реально никак по-другому.

P.S. ax2009

[belugin]

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

А баги в ядре регистрируются, я например, весной регистрировал багу с компиляцией в IL и ее пофиксили. Только следует учесть, что это решается в порядке общей очереди - расставляют приоритеты и ставят в план.

[Logger]

В перечисленном - да. Но вообще в комментах внутри классов было.
Я думал можно было это попроще сделать.
Например inner join между датасорсами сделать или избавиться от связи датасорсов. Если я правильно понял их проблемы, то при сохранении ядро сохраняет LedgerJournalTrans, после чего дергается LedgerJournalTrans_ds.Active
а из-за него
LedgerJournalTransRcash_ds.LinkActive
а из-за него LedgerJournalTransRcash_ds.Executequery

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

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

[EVGL]

Подобные задачи нынче модно решать по-другому: http://msdn.microsoft.com/en-us/library/jj129662.aspx

[S.Kuskov]

Ещё вот интересный пост в тему axdaily: Unit of Work