Опять вопрос о слоях 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]

Quote:

Originally Posted by mazzy

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

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

[Prophetic]

Quote:

Originally Posted by mazzy

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

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

Quote:

Originally Posted by mazzy

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

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

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

[anikulichev]

Добрый день.

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

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

Quote:

Originally Posted by Prophetic

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

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

[EVGL]

Quote:

Originally Posted by mazzy

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

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

[mazzy]

Quote:

Originally Posted by EVGL

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

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

[mazzy]

Quote:

Originally Posted by Zabr

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

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

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

[Bishop]

Quote:

Originally Posted by 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]

Quote:

Originally Posted by Prophetic

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

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

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

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

[Maxim Gorbunov]

Quote:

Originally Posted by BOAL

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

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

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

[BOAL]

Quote:

Originally Posted by Maxim Gorbunov

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

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

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

[Prophetic]

Quote:

Originally Posted by BOAL

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

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

Quote:

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.

Quote:

Originally Posted by BOAL

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

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

Quote:

Originally Posted by BOAL

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

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

Quote:

Originally Posted by BOAL

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

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

Quote:

Originally Posted by 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.

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

[BOAL]

Quote:

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

С чего им тереться?
Создадутся новые поля и таблицы, все будет штатно.
А вот когда будет замена слоя на дев с ворка или с дева на ворк, там отвелится все новое точно.
Потому сам подход, описанный ккак выбранный, мне лично чужд и неприемлем.
Но и с ним жил как-то. Нужно периодически тереть дев (да-да, тереть полностью, по бразильской системе) - заменять его приложение свежим ворком, БД тоже тереть и брать с ворка, как бакап.
Тогда все пучком.

Просто это два разных (диаметрально) подхода.
У вас итоговым местом выделяния ИД является Ворк, у меня - Дев
Соотв. в вашем деве можно хоть в юсп все делать, пофиг, сборку вы делаете на ворке - и именно это и чуждо мне. Так как Ворк - это святое, какие там сборки! Руками не трогать, токо ведущему разрабу по спец пропуску.

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

Quote:

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

Ничего не начнется. От того, что в ВАР слое ИД от ЮСР ничего не отвалится, все будет настраиваться как обычно. Вот если потом заменять все на другой слой с другими ИД, то отвалится, конечно.
"Другие ИД" - это не обязательно родные для слоя или чужие в нем. Это просто новые, даже внутри слоя.

Пример. Если выгрузить ХРО, стереть за собой код, потом залить - могут быть новые ИД. Такой слой снесет настройки при замене слоем.

Quote:

Попробую сделать вывод. В моём случае самым безопасным способом ведения доработок будет использование слоя VAP.

Я выше писал уже - реально вы кодите на Ворке, признайтесь в этом себе сами. ДЕВ у вас - это разрозненные локалы (если > 1 программера).

Если на Ворке что-то кодится минуя ДЕВ (типа "быстро"), то ИД там будет занят, и заливка из ДЕВа с сохранением ИД даст конфликт. Вот и все.

Есть жесткое правило - первична та версия, где выделяются ИД.
У вас это Ворк. Потому кодте на Дев, где угодно, главное его тереть потом и заменять ворком целиком - это нормальная практика - жил так сам года 2-3, потом изменил подход.
====
Это мы еще не полезли в дебри правильного пути дао разработки на трех приложениях (дев-тест-ворк) или совсем правильного на 4х (дев-тест-демо-ворк)

(дев-ворк) - это уже путь неверный, сам в себе Но все это для внедрений толпой народу. Если 1-2 чела, то я сам за Дев-Ворк, где
Дев исполняет роли Дев, Тест, Демо.

[Prophetic]

Quote:

Originally Posted by BOAL

С чего им тереться?
Создадутся новые поля и таблицы, все будет штатно.

Т.е. в варианте №1 (CUS-CUS) всё будет нормально, поскольку в боевой базе Id для таблицы уже был выделен, будет заменено описание. Правильно?

Quote:

Originally Posted by BOAL

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

Я вообще не собирался слоями ничего переносить. Изначально был вопрос о схеме CUS-CUS, с переносом объектов в xpo, без сохранения Id.
Если у меня на деве копии объектов, с которыми я только что работал находятся в актуальном состоянии, то зачем их удалять и снова добавлять, неясно.

Quote:

Originally Posted by BOAL

Потому сам подход, описанный ккак выбранный, мне лично чужд и неприемлем.
Но и с ним жил как-то. Нужно периодически тереть дев (да-да, тереть полностью, по бразильской системе) - заменять его приложение свежим ворком, БД тоже тереть и брать с ворка, как бакап.
Тогда все пучком.

Это если подход VAP-VAP-VAR? Или опять же, CUS-CUS?

Quote:

Originally Posted by BOAL

Просто это два разных (диаметрально) подхода.

Понятно. Мне нужен один, наиболее безопасный.

Quote:

Originally Posted by BOAL

У вас итоговым местом выделяния ИД является Ворк, у меня - Дев
Соотв. в вашем деве можно хоть в юсп все делать, пофиг, сборку вы делаете на ворке - и именно это и чуждо мне. Так как Ворк - это святое, какие там сборки! Руками не трогать, токо ведущему разрабу по спец пропуску.

Так я по этой же причине ("Ворк - святое, руками не трогать") и пытаюсь выяснить безопасную схему.

Quote:

Originally Posted by BOAL

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

Судя по всему, у меня тут такое делали.

Quote:

Originally Posted by BOAL

Я выше писал уже - реально вы кодите на Ворке, признайтесь в этом себе сами. ДЕВ у вас - это разрозненные локалы (если > 1 программера).

Не признаюсь. Реально я кодировал на деве, который был копией ворка. Программер 1 -- я.

Quote:

Originally Posted by BOAL

Есть жесткое правило - первична та версия, где выделяются ИД.
У вас это Ворк. Потому кодте на Дев, где угодно, главное его тереть потом и заменять ворком целиком - это нормальная практика - жил так сам года 2-3, потом изменил подход.

Да, я уже понял насчет бразильской системы.

Quote:

Originally Posted by BOAL

====
Это мы еще не полезли в дебри правильного пути дао разработки на трех приложениях (дев-тест-ворк) или совсем правильного на 4х (дев-тест-демо-ворк)

(дев-ворк) - это уже путь неверный, сам в себе Но все это для внедрений толпой народу. Если 1-2 чела, то я сам за Дев-Ворк, где
Дев исполняет роли Дев, Тест, Демо.

До правильного дао насчет теста уже почти дошел, возможность есть.

[BOAL]

Процитирую себя:

Quote:

Пример. Если выгрузить ХРО, стереть за собой код, потом залить - могут быть новые ИД

Это к вопросу о безопасном CUS-CUS переносе через ХРО. Слой полученный заливкой в него ХРО из другого без сохранения ИД будет "другим" (уже не совместимым).

Скажем так, если вы в принципе не собираетесь когда либо копировать приложения ворк в дев, или дев в ворк, то у вас все хорошо и не важно, какие слои и ИД в них используются.
Проблемы будут, если нужно сохранить совместимость с БД, потому как при замене приложения целиком (что равно замене слоями), синхронизация предложит прибить новые (измененные) таблицы.

[Prophetic]

Quote:

Originally Posted by BOAL

Процитирую себя:

Это к вопросу о безопасном CUS-CUS переносе через ХРО. Слой полученный заливкой в него ХРО из другого без сохранения ИД будет "другим" (уже не совместимым).

Скажем так, если вы в принципе не собираетесь когда либо копировать приложения ворк в дев, или дев в ворк, то у вас все хорошо и не важно, какие слои и ИД в них используются.
Проблемы будут, если нужно сохранить совместимость с БД, потому как при замене приложения целиком (что равно замене слоями), синхронизация предложит прибить новые (измененные) таблицы.

Здорово. Подытожу то, что я понял для своей ситуации: я могу смело кодить в деве на CUS слое, и переносить объекты на CUS слой в ворк с помощью XPO без идентификаторов. Данные в изменяемых таблицах на ворке никуда не денутся.