Погода: 1 °C
21.11−4...1пасмурно, без осадков
22.11−6...−2переменная облачность, небольшой снег
  • Привет акулам 1С! Досталась задача - обновить нетиповую конфигурацию на приличное количество релизов. Собственно, как истинный программист, я сразу же бросился придумывать, как это лучше сделать... пришла идея выгрузить дифф между основной конфигурацией и конфигурацией поставщика (т.е. по сути сторонние доработки нетиповой конфы), обновить все релизы, а в самом конце просто накатить этот дифф на самый последний релиз. Собственно, вопрос - реально ли это сделать? Потому что механизмы у 1С, прямо сказать, не прозрачные. Решить конфликты в самом конце, все скопом и ровно один раз - я бы сделал именно так, но возможно ли?

    Даже если ну никак - ладно, я смирюсь с такой кривотой и буду последовательно ставить все обновления, решая на каждом этапе конфликты. НО, меня интересует следующая ситуация (сразу оговорюсь, я не знаю 1С от слова "вообще", поэтому опишу ситуацию на псевдоязыке):
    В основной конфигурации сторонними разработчиками написан класс B, который является потомком класса А (он есть в старой конфигурации поставщика). Класс А имеет публичные (никакой инкапсуляции, только хардкод) поля "name" и "surname". Где-то в коде этот класс (В) используется, например, выводится "surname". Ставлю обновление - в классе А поле surname удалено. При этом весь остальной код в новой конфигурации поставщика, естественно, использует обновленный класс А, чтобы корректно работать (ведь релиз официальный). Конфликтов в этом случае не будет: класс А успешно перекочует с полями из новой конфигурации поставщика, наш класс В, написанный в отдельном файле, будет тоже успешно перенесен. Проблема только в одном: как только мы начнем использовать вывод "surname" из объекта класса В где-то в своем коде, все упадет))
    Иными словами - с какой вероятностью может возникнуть ситуация, что введенные производителем изменения нужно будет адаптировать под написанный собственноручно (не мной) код? Потому что решить конфликты - это одно, а вот чтобы все работало потом - это другое:улыб:

  • В ответ на: (сразу оговорюсь, я не знаю 1С от слова "вообще",
    Займитесь лучше тем, что знаете.

  • В ответ на: В основной конфигурации сторонними разработчиками написан класс B, который является потомком класса А (он есть в старой конфигурации поставщика). Класс А имеет публичные (никакой инкапсуляции, только хардкод)
    ну блин.. в инете фигни начитались...
    а воообще всегда адаптируются сделанные изменения 1С в код, который дописан сторонними программистами а не наоборот

    Мужчины интересуются только теми женщинами, которым они интересны...

  • В ответ на: Иными словами - с какой вероятностью может возникнуть ситуация, что введенные производителем изменения нужно будет адаптировать под написанный собственноручно (не мной) код?
    Достаточно часто возникают такие ситуации. Поэтому обновление нетиповых - довольно большой геморрой. Приходится вникать в логику других разработчиков.
    А вообще, когда не знаете 1С - лучше не лезьте в обновление нетиповых. Это как человеку, не знакомому с медициной (максимум прочитавшему учебнк по анатомию) поручить операцию по удалению аппендицита.

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

  • Варианта два - отказаться от задачи или найти исполнителя с опытом. Сами запорете с большой вероятностью БД.
    В Ваших терминах: велика вероятность того, что типовой "класс" А мог измениться в обновлениях, а вы эти изменения затрете накатыванием "диффа"

Записей на странице:

Перейти в форум

Модераторы: