С Id или без Id?

[RVS]

Тут некоторые продвинутые программисты предлагают плевать на Id объектов при переносе доработок на Production. Ну, мешают они им свободно жыть )))

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

Не поможете, с умными мыслями?

DAX2009, да.

[oip]

Тут нет однозначено правильного ответа. Смотря какую цель преследуете. На разных проектах разные регламенты. У переноса проектами с сохранением Id плюс только один - можно быстро БД с Prod на Test восстановить. Но опыт показываетя, что это недолго происходит - рано или поздно Id все равно разъезжаются. Это же все до первой ошибки при переносе, когда забыл чекбокс поставить. Я на 95% проектов для древних версий переносил без сохранения Id, а актуальность тестовых данных обеспечивал другими способами.

А в AX2012 вообще нельзя с сохранением Id проекты переносить и вопрос стал неактуальным.

[RVS]

Цитата:

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

У переноса проектами с сохранением Id плюс только один - можно быстро БД с Prod на Test восстановить

Это достаточно "хищный" плюс, согласитесь.

Цитата:

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

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

Ну, чекбокс можно просто принудительно поставить, и запретить снимать.

Тут вопрос в другом - есть любители посоздавать объекты непосредственно на Prod... и очень хотелось бы их от этого отучить. Id, ИМХО - один из методов это сделать.

Цитата:

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

в AX2012 вообще нельзя с сохранением Id проекты переносить и вопрос стал неактуальным.

Знаю. Мне тоже много, что не нравится в 12-й )))

[mazzy]

Цитата:

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

Тут некоторые продвинутые программисты предлагают плевать на Id объектов при переносе доработок на Production.

и в целом, это правильный подход.

Цитата:

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

Ну, мешают они им свободно жыть )))

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

в ранних Аксаптах было принято хранить в базе tableId/FieldId.
такого много в настройках складских аналитик, в markup и в других местах.

если на проекте также используется метод хранения идентификаторов объектов, то смена идентификаторов в базе - нетривиальная задача.

в остальном - совершенно без разницы id или имена объектов.

===========
Отвлеченное рассуждение 1:
вообще говоря, в других инструментах где практикуется "код как настройка" вполне обходятся без числовых идентификаторов, используются обычные имена

Отвлеченное рассуждение 2:
вообще говоря, в других IDE есть вполне рабочий инструмент "Рефакторинг \ Переименование". Это переименование вполне находит используемые имена и вполне успешно переименовывает. И в коде, и в конфиг-файлах и в остальных местах. В Аксапте подобный инструмент называется "Синтаксическое переименование" и работает через перекрестные ссылки. Для пользовательских данных в Аксапте есть "Паспорт записи \ переименование кода".

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

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

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

очень прикольно.

Цитата:

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

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

если в базе нет (или мало) идентификаторов объектов, то не тормозите их.
С именами (естественными ключами) работать удобнее.

Но решение должно быть осознанным. Как и в остальных областях.

Цитата:

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

Тут вопрос в другом - есть любители посоздавать объекты непосредственно на Prod... и очень хотелось бы их от этого отучить. Id, ИМХО - один из методов это сделать.

угу.
а есть еще любители посоздавать объекты из кода (в стандартной аксапте всякие модули Зарплат, например. в старой аксапте ProductBuilder)

Цитата:

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

Знаю. Мне тоже много, что не нравится в 12-й )))

Зря.

Понаблюдайте как идет программирование/конфигурирование в других инструментах.
Вспомните где используются идентификаторы (SIDы всякие, идентификаторы групп в линуксах, коды тем и сообщений на форумах)
а где используются просто имена (url, современные блоги, docker-файлы, nuget-пакеты, npm-пакеты, maven-gradle, электронная почта и много где)

[Raven Melancholic]

Цитата:

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

Тут вопрос в другом - есть любители посоздавать объекты непосредственно на Prod... и очень хотелось бы их от этого отучить

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

[trud]

Цитата:

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

Это достаточно "хищный" плюс, согласитесь.

На самом деле при восстановлении вам все равно придется в версии что-то менять(типа различный параметры интеграции и прочее).
Для актуализации ID можно использовать вот такой джоб - если данные АХ отличаются от таблицы SQLDictionary, он корректирует таблицу.
https://github.com/TrudAX/TRUDScript...Dictionary.xpo
Просто вставьте его одним из шагов

[mazzy]

Цитата:

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

На самом деле при восстановлении вам все равно придется в версии что-то менять(типа различный параметры интеграции и прочее).

не надо менять.
"параметры интеграции и прочее" надо вынести за аксапту в конфигурационные файлы, которые не будут копироваться
https://github.com/mazzy-ax/SysConfigFile

Цитата:

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

Для актуализации ID можно использовать вот такой джоб - если данные АХ отличаются от таблицы SQLDictionary, он корректирует таблицу.

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

в общем, подходы разные.

[trud]

Цитата:

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

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

Интерестно. но я что-то не понял идеи, откуда этот файл возьмется к примеру на новом АОСе. И как гарантируется что у одного окружения(к примеру прод - 3 аоса) будут одинаковые файлы?

[Raven Melancholic]

Цитата:

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

А в AX2012 вообще нельзя с сохранением Id проекты переносить и вопрос стал неактуальным.

Но остались еще некоторые вещи, в которых ID важен. Например, некоторые relations между таблицами, когда пишут RefTableId = 101234.
Буквально вчера понадобилось расширить ExtCodeTable. При переносе на TEST и STAGE придется после переноса проекта не забыть поменять число с моей таблицей.
PS: хорошо что со STAGE на PROD хранилищем обновляемся.
А не, вру, табличку расширял AifEndpointActionValueMap, в ExtCodeTable проще.

[sukhanchik]

Цитата:

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

Тут некоторые продвинутые программисты предлагают плевать на Id объектов при переносе доработок на Production.

DAX2009, да.

Тут еще неплохо бы уточнить - ведь проблема возникает исключительно при переносе через XPO, т.е. перенос происходит не приложением.
В связи с этим вопрос - все после переноса в своих классах делают инкрементную компиляцию? Или на Production запросто могут быть наследники, которые ничего не знают об изменении родителей?
Ну или на Prod регулярно делается глобальная компиляция и регулярно перестартовываются АОСы

Нельзя на Prod накатывать обновления приложением, если ID-шники разъехались между Prod и тем приложением, с которого выполняется накат.

[Logger]

Ид можно все же при экспорте сохранять в 2012-й. Но немного извращенным способом.
Нужно написать простую обработку на деве, которая пройдется по всем узлам и заполнит legacyId. Затем выгрузит проект в xpo. Удалит свежие узлы. Импортнет из xpo обратно.

Это приведет к тому что во всех узлах заполнен legacyId и он же равен обычному id. Если разово надо, то можно без обработки вручную сделать.

Затем при переносе через xpo ядро присвоит идентификаторам в тесте и проде значнния равные legacyId. Это выглядит, словно обычный перенос с сохранением идентификаторов.

[mazzy]

И еще:

внутри Аксапты Dict-классы работают с ID объектов, а TreeNode работает с наименованиями.

если вспомнить инструменты интеграции AIF, DMF, DataEnity, OData, то там никаких идентификаторов

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

[lvan]

почему эта тема возникла в 2020 году?
хотя у меня была проблема с ID - создал модель, а потом микросовт тоже создал, с таким же ID
и обновление файлилось из-за этого