Разработка на usp слое

[Murlin]

Доброго времени суток.

Дело в том что я решил включить разработку на usp слое для наших местных доработок, но второй программист почему то очень против.
Разрешите наш спор!
На сегодняшний день мы имеем готовый функционал на usr слое, который периодически должен будет обновляться, но заноситься он сравнением.
Работая на usr слое мы переписываем написанный функционал и затираем его, кроме того имеем очень много функционала который нам пока не нужен или вообще не нужен.
Не имея лучшего я предложил делать наши местные доработки на usp слое.
Возник спор. Мне не объяснили фактически какие минусы мы будем иметь кроме того что делать этого не нужно.
Вот собственно сообщение:

Цитата:

Для начала, зачем вообще нужны слои: они позволяют разделить разработку, ведущуюся разными организациями и/или для разных рынков/клиентов. т.е., скажем, вынести базовый (общий для всех) функционал на слой sys, какие-то региональные доработки – на слой gls, доработки отдельных внедренцев - на слои var/bus, доработки под конкретного клиента, а то, что сам клиент для себя лично дорабатывает, – на слой usr. Слои позволяют четко разнести модификации, сделанные разными компаниями или сторонами (внедренцем и заказчиком), кроме того, поскольку в Аксапте очень много завязок на внутренние идентификаторы объектов приложения (таблиц, полей, типов, классов, etc), для слоев выделяются непересекающиеся диапазоны идентификаторов, например, для sys - 1..16000, для usr - 50001-65000 (примерно, последние несско сотен используются объектами и типами ядра).

За счет этого, если одновременно создавать новые объекты на разных слоях и затем свести эти слои в рамках одного приложения, такие объекты гарантированно не пересекутся по идентификаторам (остается вариант пересечения по именам, но это контролировать проще, скажем, за счет использования префиксов/суффиксов). Это позволяет системе «не путаться» в них и рассматривать как различные объекты, а не как модификации одного и того же объекта. При модификации же объекта из нижележащего слоя он «поднимается» на слой, на котором ведется текущая разработка, с сохранением исходного идентификатора, и система при выполнении приложения использует копию объекта из самого верхнего слоя.

Таким образом, разведение функционала на слои и использование непересекающихся диапазонов идентификаторов позволяет четко отделить базовые разработки от собственных и, кроме того, позволяет относительно легко переносить собственные модификации при изменении приложения в "нижележащих" слоях: выпустили новый SP - слои с ним можно подложить в приложение вместо существующих, создать проект сравнения слоев на базе модификаций на том же usr-слое и быстренько эти модификации обновить для соответствия тому, что появилось в SP. Это удобно, когда изменения в "нижележащих" слоях происходят относительно часто, скажем, раз в полгода-год. К слову, для облегчения выпуска обновлений кроме «обычных» существуют и так называемые patch-слои; их имена соответствую именам «обычных» слоев, только заканчиваются на “p”: sys – syp, gls – glp, cus – cup, usr – usp. Ядро считает patch-слои расположенными «выше» соответствующих «обычных» слоев, т.е. при определении того, какую копию модифицированного объекта использовать, копия с patch-слоя имеет приоритет над копией из соотв. «обычного» слоя. Так вот, patch-слои не предназначены для «обычной» разработки, поскольку они используют тот же диапазон идентификаторов, что и соответствующий «обычный» слой; назначение patch-слоев – удобная форма выпуска исправлений для того или иного «основного» слоя: такие исправления, собранные в виде слоя, в отличие от исправлений в виде файлов экспорта (XPO), позволяют клиентам легко и быстро их накатывать. Если же вести разработку одновременно и в обычным, и в patch-слое, то объекты приложения в них почти наверняка пересекутся по идентификаторам, что может привести к непредсказуемым последствиям.

Например, в копии приложения без patch-слоя (приложение А) в «обычном» слое (usr) создается новый числовой тип данных IntType1, в таблицах создаются поля на базе этого типа. В это же время в другой копии исходного приложения с patch-слоем (приложение В) на этом слое создается строковый тип данных StrType2 с идентификатором, совпадающим с IntType1 из приложения А. В этом случае, если потом в приложение В подложить измененный usr-слой из приложения А, система подумает, что IntType1 и StrType2 – это один и тот же объект, а его копия на usp-слое – всего лишь модификация исходного объекта, а не отдельный не связанный с исходным тип.

При очередной синхронизации словаря данных будут созданы поля не целочисленного типа IntType1, с строгого типа StrType2, формы и код приложения начнут работать некорректно, полезут ошибки, но исправить их будет сложно, потому что нельзя будет просто удалить тип StrType2 с usr-слоя: возможно, на него уже ссылаются другие табличные поля или элементы управления на формах/отчетах. Аналогичные «сюрпризы» могут произойти при пересечении идентификаторов классов. В приложении методы классов ссылаются на класс, к которому они относятся, по идентификатору.

Если на слое usr в приложении А есть класс Class1 с определенным идентификатором и методом run(), выполняющим основную логику класса, в приложении В на usp-слое есть класс Class2 с таким же идентификатором и «своим» методом run(), то при подкладывании в приложение В usr-слоя из приложения А класс Class1 перестанет работать корректно, потому что система посчитает, что эти два класса – копии одного и того же (исходная и модифицированная), и будет для класса Class1 вызывать метод run() из Class2…

Еще раз: patch-слои предназначены только для выпуска обновлений и исправлений для уже созданных объектов приложения, но никак не для самостоятельной разработки на этих слоях, предусматривающей создание новых объектов приложения. Непонятно, какие плюсы кто-либо мог увидеть в разработке на usp-слое - по-моему, от этого могут быть лишь одни проблемы.

Если же в приведенных примерах не заменять периодически слой usr приложения В слоем из приложения А, то тогда вообще непонятно, зачем в приложении В вести разработку на отдельном слое.

Разве таже проблема с дублированием идентификаторов не будет возникать без usp слоя?

[mazzy]

Цитата:

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

Не имея лучшего я предложил делать наши местные доработки на usp слое.

Пробовал так. Это было давно. Сталкивался с глюком, когда работа нового объекта на usp-слое приводила к краху системы.

Для себя "придумал объяснение", что usP - это патч-слой. И разработчики предполагали, что в этом слое будут изменения уже существующих объектов. Поэтому появление новых объектов на этом слое не предусматривали, не тестировали.

С тех пор на usp-слое не программирую новых объектов.
Возможно, с тех давних пор что-то и изменилось.

[S.Kuskov]

Цитата:

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

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

Идентификаторы объектов могут пересекаться только если вести разработку в разных приложениях. И в этом случае абсолютно не важно patch-слой это или тот же самый.

Если вы хотите вести разработку в нескольких приложениях, то переход на patch-слой вам не поможет - нужно переходить на слои из разных диапазонов идентификаторов. Например на одном приложении разрабатывать в слое usr, а на другом - в слое var. Но это ли вам надо?

Ещё хочу напомнить о такой возможности, как каталог OLD в папке приложения. В который можно безболезненно подложить хоть patch-слой хоть тот же самый.

[Murlin]

Цитата:

Сообщение от S.Kuskov

Идентификаторы объектов могут пересекаться только если вести разработку в разных приложениях. И в этом случае абсолютно не важно patch-слой это или тот же самый.

Если вы хотите вести разработку в нескольких приложениях, то переход на patch-слой вам не поможет - нужно переходить на слои из разных диапазонов идентификаторов. Например на одном приложении разрабатывать в слое usr, а на другом - в слое var. Но это ли вам надо?

Ещё хочу напомнить о такой возможности, как каталог OLD в папке приложения. В который можно безболезненно подложить хоть patch-слой хоть тот же самый.

Тут вся фишка в том что мы не просто подкладываем usr слой, а заносим изменения xpo файлом, значит проблема дублирования идентификаторов отпадает???
Вот мне и интересно какие кроме это последствия могут быть?

[sukhanchik]

Цитата:

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

Тут вся фишка в том что мы не просто подкладываем usr слой, а заносим изменения xpo файлом, значит проблема дублирования идентификаторов отпадает???

За исключением того, что импорт в нижний слой объекта, измененного на верхнем слое может себя повести не так как ожидаете. Например объект может глючить. Или все изменения зальются сразу в usp. Т.е. xpo можно (гарантированно без последствий) заливать только в верхний слой (конечно только если объект лежит на нескольких слоях).

А так - конкретно usp-слой - я бы оставил "на всякий случай" как самый верхний слой. Иногда его не хватает.. Например - заливаешь большой xpo и смотришь все изменения (актуально при переходе на сервис-пак/ролап/большой хотфикс)

[Murlin]

Цитата:

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

За исключением того, что импорт в нижний слой объекта, измененного на верхнем слое может себя повести не так как ожидаете. Например объект может глючить. Или все изменения зальются сразу в usp. Т.е. xpo можно (гарантированно без последствий) заливать только в верхний слой (конечно только если объект лежит на нескольких слоях).

А так - конкретно usp-слой - я бы оставил "на всякий случай" как самый верхний слой. Иногда его не хватает.. Например - заливаешь большой xpo и смотришь все изменения (актуально при переходе на сервис-пак/ролап/большой хотфикс)

То есть я понимаю что при таком способе никакого пересечения id не будет?
Таблица с usr слоя с другого приложения будет занесена с новым id которого нет ни на usr ни на usp?
только что попробовал сделать такое и в принципе все занеслось на usp слой, с нормальным id. Не пробовал пока только заносить в usr.

[sukhanchik]

Цитата:

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

Таблица с usr слоя с другого приложения будет занесена с новым id которого нет ни на usr ни на usp?

Не будет. У usr-usp сквозная нумерация по id-шникам

[mazzy]

Цитата:

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

Так вот, patch-слои не предназначены для «обычной» разработки, поскольку они используют тот же диапазон идентификаторов...

ну, с идентификаторами - вопрос решаемый.
Особенно, если вы "для себя" прогаете, а не на продажу.

Гемор, конечно, но вполне решаемо административными мерами.

Цитата:

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

patch-слои предназначены только для выпуска обновлений и исправлений для уже созданных объектов приложения

А вот с этим - согласен.

[kornix]

Похожий вопрос задавался тут и еще можете почитать здесь. О! И еще тут и кое что здесь, может это разрешит ваш спор

[gl00mie]

Цитата:

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

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

Цитата:

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

Тут вся фишка в том что мы не просто подкладываем usr слой, а заносим изменения xpo файлом

Так зачем же все-таки вам вести разработку на usp-слое? Какие проблемы вы хотите решить таким образом? Что сейчас мешает вести собственные доработки "сбоку" на том же usr-слое, где находится "пока" и "вообще" не нужный функционал? Если вы просто хотите иметь возможность вернуться к тому коду, который вы переписываете и затираете, то храните его в old-каталоге и все. Зачем придумывать себе лишние трудности, которые самим же потом придется преодолевать? Или, может, вы думаете, что за счет разработки на другом слое при "занесении изменений" на usr вам меньше придется потом сравнивать объекты и сливать изменения? Если так, то это заблуждение...

[Murlin]

Цитата:

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

Так зачем же все-таки вам вести разработку на usp-слое? Какие проблемы вы хотите решить таким образом? Что сейчас мешает вести собственные доработки "сбоку" на том же usr-слое, где находится "пока" и "вообще" не нужный функционал? Если вы просто хотите иметь возможность вернуться к тому коду, который вы переписываете и затираете, то храните его в old-каталоге и все. Зачем придумывать себе лишние трудности, которые самим же потом придется преодолевать? Или, может, вы думаете, что за счет разработки на другом слое при "занесении изменений" на usr вам меньше придется потом сравнивать объекты и сливать изменения? Если так, то это заблуждение...

А почему нет? Ну при условии что импорт в usr происходил бы конкретно в usr, с другим id отсутствующим в базе, но раз тут говорили о том что вноситься изменения то в usp а то в usr в независимости от того откуда сам взят xpo, то все отпадает данный вариант. Заодно было бы видно что и где конкретно не работает. (Меньше от того что не все объекты usr затронуты usp хотя бы по этому)
Хотя можно и проверить.

[Bober]

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

[Murlin]

Цитата:

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

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

Я прислушиваюсь. Странный вывод какой то...
Нельзя ну нельзя, хорошо.... Таких нельзя еще миллион потому что кто то так сказал и захотел. Объясните почему нельзя.
Id пересекаются - нет не пересекаются.
usp глючит - неизвестно.
занесение не работает как нужно - хорошо.
В чем я собственное не прислушался?
Какой геммор я собирался сделать для разработчиков? Упростить им сведение и разработку?

[Bober]

Ноу проблем. Звиняйте если шо. Ваше дело, делайте как знаете...

[S.Kuskov]

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

А то на самом деле многие просто не понимают ради чего вы всё это затеиваете

[BOAL]

Цитата:

Сообщение от S.Kuskov

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

А то на самом деле многие просто не понимают ради чего вы всё это затеиваете

Есть обновляемый (регулярно) код рабочего приложения или нескольких (у клиентов один базовый стартап проекта). Есть множество разработчиков (пусть даже 2, тк когда 1, то это ты и есть, и проблем нет, все помнишь).
Разработка идет в пустом слое, проходи время, получаем простую дельту сбором проекта по слою (а у всех всегда разработчики все правки делали в проектах или были случаи забывания очень важной строчки. поправленной походя?)
Изучаем эту дельту простым сравнением слоев или даже так, на глазок, что там вообще менялось. Выгружаем в ХРО, опускаем на слой билда. Получаем .aod файлик по сути СервисПак.
Если у клиента были свои правки, то они их сами могут поднять на такой вот сервис пак....

Да и чего это я все описываю? Пример? А обновление самих СервисПаков почему идет слоями? Был бы один слой и всех дел, как в 1С слияние конфигураций и всем счастье, ан нет, АХ идет в куче слоев.

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

В общем, слои - это отличный инструмент, которым можно и не пользоваться. Возможность подкладки их в виде файлов - конкурентное преимущество над другими системами, где этого нет, которое будет возможно убито в АХ6 убиранием такой опции (весь код в БД). Просто даже сами разработчики в МС уже не понимают этого, вот им это и не нужно, пришли новые ребята и давай кодить, устраняя "фатальный недостаток" дамгардовской еще архитектуры АХ. Это и ясно, есть два уровня приближенности к практическому использованию - внедренцы (и конечные клиенты) и вендоры.
Скорость разработки, поддержки, обновления сложноизменненнго приложения - вот текущие преимущества платформы. Жаль на фоне новых фич терять старые. Эволюция, однако.

[S.Kuskov]

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

Цитата:

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

Дело в том что я решил включить разработку на usp слое для наших местных доработок ...

[Murlin]

Цитата:

Сообщение от S.Kuskov

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

Мы имеем приложение московское которое дописываем и переписываем под наши собственные нужды. Разве не тоже самое как и вообще обычная разработка на любом слое??? Копирование это приложение произошло в апреле месяце последний раз если не раньше, есть функционал в московском приложении которого нет в нашем, но мы дописали и свой и переписали имеющийся. Я пробовал занести функционал, которого мы не имеем. Но я найти то чего у нас нет не могу за ограниченное время!!! Потому что один проект завязан на другой. Если бы это все делалось как положено в отдельном слое, а филиалам отдавали usr слой то проблем было бы меньше. А теперь чтобы занести все это я должен сравнить наш usr с московским при том при всем что наш usr слой уже изменен значительно.
Что это как не разные приложения?
Что дает случай если usp работал бы нормально
Первое как я рисую себе схему, возможно я ошибаюсь:
Мы копируем функционал usr слоя москвы на чистое приложение.
Сравниваем с более низкими слоями.
Создаем проект, заносим его на нашу базу в usr слой, отсутствующим объектам назначаются новые а не существующие идентификаторы. То чего у нас не было будет лежать на usr. А то что было изменено сразу же видим. Сравниваем usp И usr и заносим изменения с учетом наших.
Но к сожалению я тоже уже думаю что теперь будет очень много проблем, так как разработка длительное время велась на usr.

[S.Kuskov]

Цитата:

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

Что это как не разные приложения?

Действительно, они и есть. Теперь я понял вашу проблему. Но решал бы я её всё-таки немного по другому. Для совмещения двух приложений действительно логично иметь два слоя. Но внимание использование одновременно двух слоёв оправдано только в момент установки обновления. Т.е. я бы собственную разработку продолжал бы вести в usr, а для заливки обновления временно пользовался бы usp.

Ещё уточняющий вопрос. Обновления базового приложения из центра к вам поступают в виде xpo или в виде слоя?

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

Возможно, я неправ. А почему "московское приложение" не использует нижние слои, например, CUS (если приложение разрабатывает клиент) или VAR (если приложение разрабатывает партнёр)? Тогда "филиал" сможет вести свою разработку на USR и слой USP останется для экстренных случаев.