Разработка на 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-слой хоть тот же самый.

[mazzy]

Цитата:

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

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

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

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

Цитата:

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

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

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

[kornix]

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

[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-шникам

[S.Kuskov]

Цитата:

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

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

Не будет? Т.е. таблица не загрузится? Или не будет, в смысле пересечения id не будет?

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

[sukhanchik]

Цитата:

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

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

Именно так и будет. Не будет пересечений. А id при загрузке на usp присвоится из того же загружаемого диапазона что и usr

[Murlin]

Цитата:

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

Не будет? Т.е. таблица не загрузится? Или не будет, в смысле пересечения id не будет?

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

Не понял ничего!
Будет пересечение id да или нет?

[lev]

Цитата:

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

Не понял ничего!
Будет пересечение id да или нет?

нет, пересечений не будет.
переносить надо будет без сохранения id.

[Murlin]

Цитата:

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

нет, пересечений не будет.
переносить надо будет без сохранения id.

Спасибо всем большое.

[gl00mie]

Цитата:

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

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

Цитата:

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

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

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

[BOAL]

Уже не раз обсуждали идеологию слоеных разработок.
С sukhanchik'ом имели опыт разных приложений с разными слоями, где шло обновление КАС слоя, как СП вниз под ЮСР с основным кодом.

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

[Murlin]

Цитата:

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

Уже не раз обсуждали идеологию слоеных разработок.
С sukhanchik'ом имели опыт разных приложений с разными слоями, где шло обновление КАС слоя, как СП вниз под ЮСР с основным кодом.

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

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

[Murlin]

Цитата:

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

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

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

[Bober]

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

[Murlin]

Цитата:

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

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

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