Опять вопрос о слоях DAX 4.0

[Prophetic]

Здравия всем.

Недавно приступил к доработками сильно модифицирванного функционала DAX 4.0. Доработки велись на слое VAR. Насколько я понял, программистам конечного пользователя системы рекомендуется вести доработки в CAS слое, что я и планирую делать для новых доработок (поправьте, если я не прав).
Возникла потребность модифицировать объекты из предыдущих доработок. Они размещены в VAR слое. Доступ к этому слою есть.
Подскажите, пожалуйста, наиболее безопасный алгоритм работы с доработками на VAR слое.
Заранее благодарен.

[mazzy]

прежде всего: слои нужны не для РАЗРАБОТКИ.

т.е. утверждение: "рекомендуется вести доработки в CUS слое" не совсем корректное.
доработки лучше вести в USR слое. А вот окончательную, отлаженную, стабильную версию поднимать на CUS.

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

Т.е. если вы работаете в CUS или USR, то вы не сможете изменять объекты из VAR слоя.
Чтобы изменить объекты VAR слоя, вы должны в конфигурационной утилите ввести пароль доступа к слою VAR и войти в слой VAR.
Находясь в CUS вы сможете изменить код классов, но не сможете изменить объявления методов (список и тип переменных, тип возвращаемого значения)
Это сделано сознательно.

Еще раз:
1. рекомендуется доработки вести в USR
2. в вышестоящие слои рекомендуется переносить стабильные версии

[Zabr]

Цитата:

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

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

Небольшой оффтоп: крайне неудачно придумано (не знаю кем, наверное ещеразработчиками Дамгаарда) называть более стабильные слои вышестоящими. Надо бы наоборот. Фундамент - разработка самого Микрософта, выше - региональные разработки, выше - разработки партнеров, и на самом верху - разработки программистов клиента. А сейчас получается зависшая в воздухе перевернутая пирамида.
Это оффтоп, отвечать не обязательно.

[mazzy]

Цитата:

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

Небольшой оффтоп: крайне неудачно придумано (не знаю кем, наверное ещеразработчиками Дамгаарда) называть более стабильные слои вышестоящими. Надо бы наоборот. Фундамент - разработка самого Микрософта, выше - региональные разработки, выше - разработки партнеров, и на самом верху - разработки программистов клиента. А сейчас получается зависшая в воздухе перевернутая пирамида.

Сейчас на мастер-классе Еременко рассказывать про слои и апгрейд с предыдущих версий.
Он правильно говорит. И слайды у него правильно нарисованы - Майксрофот внизу как фундамент.

Это я неправильно выражаюсь.
А путаница выше/ниже происходит из списка слоев в конфигурационной утилите

[Prophetic]

Цитата:

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

доработки лучше вести в USR слое. А вот окончательную, отлаженную, стабильную версию поднимать на CUS.

USR -- самый верхний слой, тогда немного непонятно, как на CAS его "поднимать".

Цитата:

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

Еще раз:
1. рекомендуется доработки вести в USR
2. в вышестоящие слои рекомендуется переносить стабильные версии

Правильное прочтение -- в нижестоящие слои?

А так -- почти все понятно со слоями. Благодарю.

[Михаил Андреев]

Цитата:

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

USR -- самый верхний слой, тогда немного непонятно, как на CAS его "поднимать".

Самый верхний - USP, а не USR. CAS слоя нет, есть CUS.
Процедуры описаны, например, здесь: http://msdn.microsoft.com/en-us/library/aa892084.aspx

[EVGL]

Цитата:

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

Еще раз:
1. рекомендуется доработки вести в USR
2. в вышестоящие слои рекомендуется переносить стабильные версии

Кем рекомендуется? При наличии системы контроля версий разработку можно вести в каком угодно слое.

[mazzy]

Цитата:

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

Кем рекомендуется? При наличии системы контроля версий разработку можно вести в каком угодно слое.

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

[anikulichev]

Добрый день.

Прочитайте книжку Incide Dynamics Часть 1->Глава 1->Технология слоев прикладной модели, страница 40. Там все прекрасно описано какие слои, для чего и где вести разработку.

[Bishop]

Цитата:

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

Здравия всем.

Недавно приступил к доработками сильно модифицирванного функционала DAX 4.0. Доработки велись на слое VAR. Насколько я понял, программистам конечного пользователя системы рекомендуется вести доработки в CAS слое, что я и планирую делать для новых доработок (поправьте, если я не прав).
Возникла потребность модифицировать объекты из предыдущих доработок. Они размещены в VAR слое. Доступ к этому слою есть.
Подскажите, пожалуйста, наиболее безопасный алгоритм работы с доработками на VAR слое.
Заранее благодарен.

Если доработки на слое VAR достались вам от компании-внедренца, то лучше вообще не вносить изменения в этот слой. Начинайте доработку на слое CUS, переопределяя и модифицируя необходимые объекты. Таким образом, вы в любой момент сможете увидеть, какие изменения именно вы внесли в систему, и сохраните структурную целостность процесса внедрения. Я бы делал так.
Это справедливо, если вы не собираетесь удалять/переименовывать объекты на слое VAR.

[BOAL]

Если разработчик-внедренец, то лучше USR и USP оставлять пустыми для:
USR - работы кодеров клиента, в процессе внедрения слой по жизни пустой
USP - для временных слияний кода, тк утилита сравнения ущербна, лучше залить в ЮСП, сравнить по-человечески, и стереть за собой.
В USP так же стоит сваливать разработческие утилиты, и стирать их за собой после внедрения.
Ошибочное занятие USR для внедрения, а USP для клиента приводит к тому, что слоев просто нет для сливания ХРО (внимание! сами себе яму роете этим)

Приходим к тому, что для внедренца разрабатывать лучше в CUS слое.
При этом, если в основе проекта лежит какое-то решение (самого внедренца или чье-то), то оно должно лежать в VAR, для удобного сравнения с было-стало. И апдайтится как серфис пак, если его делает другая команда.
Слой CUP при этом может (не обязательно) использоваться для самого кодинга всей командой, а после кодревью ведущего разработчика (удобного как кас-кап дельта) опускается в кас с сохранением ИД и стирается весь кап до следующей итерации.
Важно, что между ВАР и ВАП, кас и кап, юср и юсп переносить можно (и нужно) с сохранением ИД.
А между ВАР и КАС (и прочими) - не нужно (хотя и можно), но крайне НЕ нужно.

Учесть при выборе слоев возможности заливки в запущенную рабочую АХ ХРОшек по-живому (ИД новых элементов и периодическую подмену слоев целиком).
Разобраться с SQLDictonary, понять, как после перебивки ИД (из КАС в ВАР или из ЮСР в КАС) сохранить данные, если делалось на живых данных.

Все это выстраданное ИМХО за много лет разных подходов и проектов. Не зависимо от книжек (тогда их и не было) и теорий.
Это действующая методика, дающая экономию во времени до 40-70% времени и повышающая качество за счет удобного сравнения кода и код ревью.

Сталкивался с двумя мнениями разработчиков, кто что считает верхним слоем.
Сам я фанат картинки-схемы аля слои Земли, где sys - это ядро, а usr - слой почвы
Потому термин "нижний слой" - это физически вниз , то есть в sys.

[Prophetic]

Здравия всем еще раз. Перед обновлением рабочей базы решил опять вернуться к теме слоёв. Воспользовался советами BOAL'a, и Bishop'a, за что им и всем остальными благодарность, и вёл доработки в слое CUS, но в тестовой базе, которая являлась копией рабочей. Наработки велись в проекте, который экспортировался в xpo-файл. Я планирую импортировать в рабочую базу тоже на CUS слой.

Меня терзают следующие смутные сомнения:
1. Есть проект, в котором изменена только форма, класс или отчет, без таблиц. Я буду импортировать без идентификаторов. Возможна ли потеря прав пользователей в этом случае?
2. Есть проект, в котором уже изменена таблица (добавлено одно или несколько полей) и другие объекты. Возможна ли потеря данных?
3. Есть таблицы и формы, которые были изменены на USR-слое предыдущим программистом.
Будет ли модификация их (при необходимости) на USR-слое верным выходом из ситуации?

[BOAL]

Цитата:

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

Меня терзают следующие смутные сомнения:
1. Есть проект, в котором изменена только форма, класс или отчет, без таблиц. Я буду импортировать без идентификаторов. Возможна ли потеря прав пользователей в этом случае?
2. Есть проект, в котором уже изменена таблица (добавлено одно или несколько полей) и другие объекты. Возможна ли потеря данных?
3. Есть таблицы и формы, которые были изменены на USR-слое предыдущим программистом.
Будет ли модификация их (при необходимости) на USR-слое верным выходом из ситуации?

Из того что понял
Есть КАС слой в сборе, но на тесте что-то менялось в ЮСР, который потом был аккуратно перенесен в КАС без сохранениия ИД.
Теперь хочется обновить тест, чтоб "не отвалилось"?
Да?
Сама закачка ХРО из теста в КАС может быть любой, код не потеряется.
Обновление же теста всем приложением (а замена слоя с кодом == замене приложения, тк лишний ЮСР нужно ж потереть) тоже код сохранит без проблем.
Отвалиться могут токо данные, синхронизация добродушно предложит стереть с таблицы по списку
Это тоже лечится (но это отдельная тема про SQLDictonary и закрытый в Админке АХ крайненужный пункт меню синхронизации с реиндексацией и восстановлением неверных).

По вопросам
1 Если формы, отчеты и классы были уже (то есть ИД был для правок в юср уже касный), все пучком - это нормальная практика на каждый день - у мя на рабочей все правки в юср, а заливаю слоем в вар с дева
2 - отвалится таблица. Сотрется при синхронизации. (тут или "тема с SQLDictonary" или ее предварительно выгрузить и загрузить обратно) - вам выгрузить проще
3. чем 3 отличается от 1 и 2 кроме автора модификаций? Вырожденный пункт

про мусор в ЮРС с ведением всего в КАС - ответ очевиден.
Если разработка в КАС - юср пустой. Соотв. да можно - нет не нужно. на то и "мусор" (временный код до перелива).

[Prophetic]

Цитата:

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

Из того что понял
Есть КАС слой в сборе, но на тесте что-то менялось в ЮСР, который потом был аккуратно перенесен в КАС без сохранениия ИД.
Теперь хочется обновить тест, чтоб "не отвалилось"?
Да?

Нет. Попробую пояснить ситуацию подробнее. Есть боевое приложение, в котором практически все наработки велись в VAR-слое. И только очень незначительная часть работы велась в USR-слое (видимо, для быстрых доработок).
Я сделал копию рабочего приложения на другой сервер AOS, и другой сервер SQL - дев-приложение. Планировалось вести доработки на дев-приложении, на слое CUS. После утверждения, доработка экспортируется в xpo-файл, а затем импортируется в боевое приложение в слой CUS. Возникли опасения, что после импорта на боевое приложение в слой CUS может возникнуть потеря данных в таблицах, которые уже живут. Хотя, если я не ошибаюсь, на сайте указано, что в случае с таблицами, экспортируется только измененная часть (добавленные, измененные поля). Вот здесь:
http://msdn.microsoft.com/en-us/libr...8AX.10%29.aspx

Цитата:

Tables and classes are special cases

Tables and classes are special cases in the sense that they may have sub nodes that are saved in different layers. For example, the table Tab1 in the SYS layer may have a field, Field1, that exists both in the SYS and in the USR layer.

When you export the USR layer, the Tab1 tables is exported as well but the export file will hold only the description of Field1 and not the remainder of the table. When Tab1 is subsequently imported, only Field1 is affected.

Цитата:

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

Сама закачка ХРО из теста в КАС может быть любой, код не потеряется.

С кодом понятно, с данными пока нет. Т.е., если я добавлю новое поле в таблице на слое CUS в дев-приложении, потом перенесу в боевое-приложение на CUS-слой xpo-файлом эту таблицу, то данные в боевом приложении не потеряются?

Цитата:

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

Обновление же теста всем приложением (а замена слоя с кодом == замене приложения, тк лишний ЮСР нужно ж потереть) тоже код сохранит без проблем.
Отвалиться могут токо данные, синхронизация добродушно предложит стереть с таблицы по списку
Это тоже лечится (но это отдельная тема про SQLDictonary и закрытый в Админке АХ крайненужный пункт меню синхронизации с реиндексацией и восстановлением неверных).

Я понял, но не планировал обновления слоями (пока). Не хочется возиться с лечением.

Цитата:

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

По вопросам
1 Если формы, отчеты и классы были уже (то есть ИД был для правок в юср уже касный), все пучком - это нормальная практика на каждый день - у мя на рабочей все правки в юср, а заливаю слоем в вар с дева
2 - отвалится таблица. Сотрется при синхронизации. (тут или "тема с SQLDictonary" или ее предварительно выгрузить и загрузить обратно) - вам выгрузить проще
3. чем 3 отличается от 1 и 2 кроме автора модификаций? Вырожденный пункт

1 понятно, 2 - тоже, но возиться с загрузкой выгрузкой данных на боевом приложении не всегда приятно.

Цитата:

Сообщение от Maxim Gorbunov

Между VAR и CUS все-таки с ID перенести нельзя. Диапазоны разные

2 Prophetic
Каждый слой (а точнее, пара основной слой + патч-слой) имеет свой диапазон ID. Например, ID всех объектов VAR-VAP слоя находится в диапазоне 30001-40000, а ID всех объектов CUS-CUP слоя - в диапазоне 40001-50000. Если вы переносите объект с CUS на VAR, ему будет выделен новый ID.

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


Попробую сделать вывод. В моём случае самым безопасным способом ведения доработок будет использование слоя VAP. Т.е. на дев-приложении на слое VAP я делаю доработки, и после утверждения этот проект переношу через xpo-файл на боевое приложение, на VAR-слой с сохранением ID. Или же, в качестве дополнительного теста, можно переносить на VAP-слой, и после дополнительного тестирования, опускать на VAR-слой, опять же, с сохранением ID.

Буду рад замечаниям и предложениям.

[Maxim Gorbunov]

Цитата:

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

Важно, что между ВАР и ВАП, кас и кап, юср и юсп переносить можно (и нужно) с сохранением ИД.
А между ВАР и КАС (и прочими) - не нужно (хотя и можно), но крайне НЕ нужно.

Между VAR и CUS все-таки с ID перенести нельзя. Диапазоны разные

2 Prophetic
Каждый слой (а точнее, пара основной слой + патч-слой) имеет свой диапазон ID. Например, ID всех объектов VAR-VAP слоя находится в диапазоне 30001-40000, а ID всех объектов CUS-CUP слоя - в диапазоне 40001-50000. Если вы переносите объект с CUS на VAR, ему будет выделен новый ID.

[BOAL]

Цитата:

Сообщение от Maxim Gorbunov

Между VAR и CUS все-таки с ID перенести нельзя. Диапазоны разные

... Если вы переносите объект с CUS на VAR, ему будет выделен новый ID.

1 Я писал о парах слоев (кас-кап, вар-вап..), а не переносе ЮСР на ВАР
2 Перенести с ЮСР на ВАР с ИД от ЮСР можно (технически все для этого есть) и АХ прекрасно потом работает (об этом изначально и был разговор). Так делают, знаю проект. Другое дело, что это просто неправильно и делать так не нужно (слово именно "не нужно", а не "нельзя").