Комментарии 36
Всё просто. 1С-Программист вообще не программист, в остальном всё правильно.
Если возьмём сферического Java/C/C++/C#/итп программиста, то за короткое время из него можно сделать программиста на любом языке.
Если возьмём 1С-Программиста, то ничего из него не сделаем — они не знают алгоритмику. Зато знают чем отличается сальдо от дебета.
Если возьмём сферического Java/C/C++/C#/итп программиста, то за короткое время из него можно сделать программиста на любом языке.
Если возьмём 1С-Программиста, то ничего из него не сделаем — они не знают алгоритмику. Зато знают чем отличается сальдо от дебета.
Сальдо = Дебет+Кредит…
ИМХО, конечно, но то, что 1С-ники не знают алгоритмику — проблема данных конкретных 1С-ников. Впрочем, достаточно распространенная, факт. Туда же и нечитаемый код, и хреновые запросы, и запросы к базе в цикле и тому подобное.
При этом, если этот 1С-ник в своей жизни кодил на чем-то более труЪ (C/C++, Python, Java, you name it), разница заметна невооруженным глазом. И по внешнему виду кода, и по производительности. Коллегам понемногу пытаюсь нестивозмездие во имя луны свет знания, вроде втягиваются.
При этом, если этот 1С-ник в своей жизни кодил на чем-то более труЪ (C/C++, Python, Java, you name it), разница заметна невооруженным глазом. И по внешнему виду кода, и по производительности. Коллегам понемногу пытаюсь нести
За короткое время можно сделать только говнокодера. Из 1Совца тоже, но не из каждого.
Если возьмём 1С-Программиста, то ничего из него не сделаем
Почему же, сделаем, у многих из 1С-ков за спиной все такое же программерское образование как и у других разработчиков. И вопреки стереотипам опыт разработки в 1С не гробит мировосприятие, а наоборот (при наличии головы на плечах) помогает набрать некоторые, очень полезные скилы, применимые и в куда более низкоуровневых ЯП.
P.S. я сам в прошлом 1С-разработчик, сейчас .Net\С#
Для правильной работы с версионными базами данных Oracle и Postgre используется собственный механизм блокировок;
ЗАЧЕМ? Ну и да там исчезли запросы вида select * from table?
ЗАЧЕМ? Ну и да там исчезли запросы вида select * from table?
Механизм ORM использующийся в платформе был изначально написан для блокировочных СУБД. Чтобы добавит поддержку версионных БД был разработан собственный механизм блокировок, который используется сейчас по умолчанию для всех новых конфигураций.
Такие запросы генерируются, когда отключен собственный механизм блокировок, чтобы делать блокировку на уровне таблицы. Этот режим сделан как заглушка, чтобы обеспечить правильность работы приложения для старых конфигураций.
Такие запросы генерируются, когда отключен собственный механизм блокировок, чтобы делать блокировку на уровне таблицы. Этот режим сделан как заглушка, чтобы обеспечить правильность работы приложения для старых конфигураций.
Механизм ORM использующийся в платформе был изначально написан для блокировочных СУБД. Чтобы добавит поддержку версионных БД был разработан собственный механизм блокировок, который используется сейчас по умолчанию для всех новых конфигураций.
Эмм. Расскажите ко мне чем отличаются стандартные уровни изоляции при управлении транзакциями между блокировочниками и версионными БД. А так же чем они не устраивали разработчиков а? Это точно опытные разработчики? Или они СУБД на картинках видели?
Такие запросы генерируются, когда отключен собственный механизм блокировок, чтобы делать блокировку на уровне таблицы. Этот режим сделан как заглушка, чтобы обеспечить правильность работы приложения для старых конфигураций.
Вы в курсе, что в PostgreSQL это как-то на запись ничего не блокирует?
Ну и да. Там убрали этот идиотский патч для PostgreSQL связанный с кривостью рук программистов?
1. Я не участвую в разработке платформы, сами разработчики тоже об этом не распространяются, поэтому могу лишь предположить, что причина в унифицированном доступе к остаткам. То есть заблокировали записи с остатками, проверили их, изменили. С версионными СУБД все по-другому, сначала их нужно изменить, а затем проверить. Если при списании остатка нужно использовать FIFO все еще сложнее. Кроме того собственный механизм блокировок оказался очень полезен даже для MS SQL Server, т.к. он очень любит эскалировать блокировки до таблицы даже для небольшого набора записей.
2. Я не могу сказать, какие запросы использует платформа, чтобы заблокировать всю таблицу в Postgre SQL. Главное что платформа это делает.
2. Я не могу сказать, какие запросы использует платформа, чтобы заблокировать всю таблицу в Postgre SQL. Главное что платформа это делает.
Я не участвую в разработке платформы, сами разработчики тоже об этом не распространяются, поэтому могу лишь предположить, что причина в унифицированном доступе к остаткам. То есть заблокировали записи с остатками, проверили их, изменили. С версионными СУБД все по-другому, сначала их нужно изменить, а затем проверить.
Эээ. Вообще это значит разработчики про «уровни изоляции транзакций» не слышали. И книжку про СУБД не читали.
Если при списании остатка нужно использовать FIFO все еще сложнее. Кроме того собственный механизм блокировок оказался очень полезен даже для MS SQL Server, т.к. он очень любит эскалировать блокировки до таблицы даже для небольшого набора записей.
Угу. Плохому танцору известно что мешает. Так что я пока своего мнения о профессионализме тех людей что делают платформу как-то не поменял. Раз люди не знают про уровни изоляции транзакций на уровне SQL-92.
Я не могу сказать, какие запросы использует платформа, чтобы заблокировать всю таблицу в Postgre SQL. Главное что платформа это делает.
Угу и проседает по производительности. Знаю я один движок который так же для записи лочит всю таблицу MyISAM называется.
Не ради флейма, но интересно — а как помогут уровни изоляции транзакций в списании товаров по FIFO?
Задача — чтобы ни при каких условиях нельзя было уйти в минус. Списывать нужно количество и сумму, сумма, естественно, берется из остатка конкретной партии и списывается пропроционально списанному количеству этой же партии…
Задача — чтобы ни при каких условиях нельзя было уйти в минус. Списывать нужно количество и сумму, сумма, естественно, берется из остатка конкретной партии и списывается пропроционально списанному количеству этой же партии…
а как помогут уровни изоляции транзакций в списании товаров по FIFO?
Задача — чтобы ни при каких условиях нельзя было уйти в минус. Списывать нужно количество и сумму, сумма, естественно, берется из остатка конкретной партии и списывается пропроционально списанному количеству этой же партии…
Вообще довольно просто. Serializable если требуется последовательность выполнения операций или Repeatable read если достаточно чтобы данные на момент их чтения не были модифицированы.
Если вы считаете что этих уровней не достаточно, то я уже готов послушать. Особенно если учесть что РСУБД обеспечивают ACID.
Задача — чтобы ни при каких условиях нельзя было уйти в минус. Списывать нужно количество и сумму, сумма, естественно, берется из остатка конкретной партии и списывается пропроционально списанному количеству этой же партии…
Вообще довольно просто. Serializable если требуется последовательность выполнения операций или Repeatable read если достаточно чтобы данные на момент их чтения не были модифицированы.
Если вы считаете что этих уровней не достаточно, то я уже готов послушать. Особенно если учесть что РСУБД обеспечивают ACID.
Т.е., получаем:
1) Начинаем транзакцию в режиме Serializable
2) Читаем остатки из таблицы остатков ||| начиная с этого момента другие транзакции их не изменят
3) Делаем расчеты
4) Записываем новые остатки и фиксируем транзакцию.
Я нигде не ошибся? Если не ошибся, то именно так всё в 1С работает с MS SQL и DB2.
А вот с PostgreSQL и Oracle так у них не получилось, что им помешало не знаю. Скорее всего по какой-то причине не могли определить автоматически, какие именно записи нужно заблокировать. И они использовали Read Comitted на всю таблицу.
С добавлением управляемых блокировок, же используется всегда Read Comitted (в том числе и для MS SQL), но уже на отдельные записи таблицы.
1) Начинаем транзакцию в режиме Serializable
2) Читаем остатки из таблицы остатков ||| начиная с этого момента другие транзакции их не изменят
3) Делаем расчеты
4) Записываем новые остатки и фиксируем транзакцию.
Я нигде не ошибся? Если не ошибся, то именно так всё в 1С работает с MS SQL и DB2.
А вот с PostgreSQL и Oracle так у них не получилось, что им помешало не знаю. Скорее всего по какой-то причине не могли определить автоматически, какие именно записи нужно заблокировать. И они использовали Read Comitted на всю таблицу.
С добавлением управляемых блокировок, же используется всегда Read Comitted (в том числе и для MS SQL), но уже на отдельные записи таблицы.
1) Начинаем транзакцию в режиме Serializable
2) Читаем остатки из таблицы остатков ||| начиная с этого момента другие транзакции их не изменят
3) Делаем расчеты
4) Записываем новые остатки и фиксируем транзакцию.
Я нигде не ошибся? Если не ошибся, то именно так всё в 1С работает с MS SQL и DB2.
Что значит именно так? Я думаю они просто не используют уровни изоляции транзакции отличные от умолчания вообще. Или используют только в общем виде. В итоге на MS SQL и DB2 это работает потому что тот что другой не версионные РСУБД, а блокировочные.
А вот с PostgreSQL и Oracle так у них не получилось, что им помешало не знаю.
Ну тем что первый версионник, а второй использует гибридную схему. В итоге это работает не так как в MS SQL и DB2.
Скорее всего по какой-то причине не могли определить автоматически, какие именно записи нужно заблокировать. И они использовали Read Comitted на всю таблицу.
Автоматически? Это вообще не их забота. Это забота РСУБД. Я думаю проблема в другом. И имя ей большой объем рефакторинга кода. Было проще адаптировать свой механизм блокировок который оставался еще с файловой версии. Как итог имеем что имеем. И да проблему они этим не решили, а только отложили.
Ну, если верить их сайту, то вполне используют. И конструкции языка запросов типа «ДЛЯ ИЗМЕНЕНИЯ» это подтверждают.
Только вот не всегда такая схема является оптимальной. Если исходить из того, что в нормально работающей системе большинство транзакций по списанию товара будут успешными, а также что именно списание по партиям — это одна специфическая задача, где результат зависит от прочитанных данных, по тем же деньгам — главное просто контроль остатка, то оптимальнее выглядит такая система:
1) Открываем транзакцию
2) Делаем расчеты
3) Записываем новые остатки и блокируем таблицу остатков
4) Проверяем, не ушли ли в минус, если не ушли — фиксируем транзакцию, иначе отменяем.
Плюс тут в том, что этап расчетов выполняется до блокировки каких-либо данных.
А механизм управляемых блокировок дает возможность разработчику определить, в какой момент что блокировать.
Может, конечно, проблема в рефакторинге — но по факту они изобрели второй механизм блокировок. А старый оставили как есть.
P.S. я абсолютно согласен с тем, что 1С велосипедисты те ещё. но их «навелосипеженные» механизмы работают довольно неплохо, и логика в них есть.
Только вот не всегда такая схема является оптимальной. Если исходить из того, что в нормально работающей системе большинство транзакций по списанию товара будут успешными, а также что именно списание по партиям — это одна специфическая задача, где результат зависит от прочитанных данных, по тем же деньгам — главное просто контроль остатка, то оптимальнее выглядит такая система:
1) Открываем транзакцию
2) Делаем расчеты
3) Записываем новые остатки и блокируем таблицу остатков
4) Проверяем, не ушли ли в минус, если не ушли — фиксируем транзакцию, иначе отменяем.
Плюс тут в том, что этап расчетов выполняется до блокировки каких-либо данных.
А механизм управляемых блокировок дает возможность разработчику определить, в какой момент что блокировать.
Может, конечно, проблема в рефакторинге — но по факту они изобрели второй механизм блокировок. А старый оставили как есть.
P.S. я абсолютно согласен с тем, что 1С велосипедисты те ещё. но их «навелосипеженные» механизмы работают довольно неплохо, и логика в них есть.
Ну, если верить их сайту, то вполне используют. И конструкции языка запросов типа «ДЛЯ ИЗМЕНЕНИЯ» это подтверждают.
У них там первый же абзац в глаза бросается. Насколько я понимаю раз они пишут в таком ключе значит у них там еще использование своего механизма транзакций не изведено в ноль.
Если исходить из того, что в нормально работающей системе большинство транзакций по списанию товара будут успешными, а также что именно списание по партиям — это одна специфическая задача, где результат зависит от прочитанных данных, по тем же деньгам — главное просто контроль остатка, то оптимальнее выглядит такая система:
1) Открываем транзакцию
2) Делаем расчеты
3) Записываем новые остатки и блокируем таблицу остатков
4) Проверяем, не ушли ли в минус, если не ушли — фиксируем транзакцию, иначе отменяем.
Плюс тут в том, что этап расчетов выполняется до блокировки каких-либо данных.
А механизм управляемых блокировок дает возможность разработчику определить, в какой момент что блокировать.
Вы не понимаете что такое транзакция. Оттуда и появляется блокировка. Если у вас максимальный уровень транзакции (Serializable), то достаточно в начале прочитать таблицу остатков. Таким образом меняем описанное выше:
1) Открываем транзакцию
2) Читаем таблицу остатков
3) Делаем расчеты
4) Проверяем, не ушли ли в минус, если ушли откат транзакции
5) Записываем новые остатки и фиксируем транзакцию.
И не надо никаких выставляемых в ручную блокировок.
но их «навелосипеженные» механизмы работают довольно неплохо, и логика в них есть.
Они не нужны. Плюс так-как они отличны от тех что приняты в предметной области получаем другое представление мира у программистов 1С.
1) Открываем транзакцию
2) Читаем таблицу остатков
3) Делаем расчеты
4) Проверяем, не ушли ли в минус, если ушли откат транзакции
5) Записываем новые остатки и фиксируем транзакцию.
И после п.2 другие транзакции не смогут выполнить п.2 у себя, верно? А тот вариант как раз дает возможность работать с данными в других транзакциях, вплоть до записи новых остатков.
Другое дело что на списании партий такой вариант не проходит, но на списании просто количества, без партий — отлично работает.
И тут достаточно уровня Read comitted с начала транзакции, а перед записью новых остатков установить Serializable, потом быстро проверить остаток и транзакцию зафиксировать/откатить.
Насколько я понял, вот как раз вместо установки Serializable в конце 1С использует свой
И после п.2 другие транзакции не смогут выполнить п.2 у себя, верно?
Они будут ждать пока завершится первая транзакция.
А тот вариант как раз дает возможность работать с данными в других транзакциях, вплоть до записи новых остатков.
Технически и тут можно. Вам просто надо транзакцию открывать на моменте проверки остатков. Но лучше так не делать.
Другое дело что на списании партий такой вариант не проходит, но на списании просто количества, без партий — отлично работает.
И тут достаточно уровня Read comitted с начала транзакции, а перед записью новых остатков установить Serializable, потом быстро проверить остаток и транзакцию зафиксировать/откатить.
Не надо так делать. Давайте поясню. В случае если вы делаете read commited то к моменту serializable у вас данные остатков могут быть не корректны. И это зависит от реализации вычисления остатков. Если это просто поле в записи, то все будет ок. А вот если у вас это вычисляемое значение по нескольким записям, то вы получите фантомное чтение, когда не будет учтен добавленный в соседней транзакции остаток.
Технически и тут можно. Вам просто надо транзакцию открывать на моменте проверки остатков. Но лучше так не делать.Тогда нельзя будет откатить изменения, не влияющие на остаток, которые записаны до открытия транзакции.
Вот если повысить уровень изоляции — то да, сработает. Но не в курсе, возможно ли такое.
Не надо так делать. Давайте поясню. В случае если вы делаете read commited то к моменту serializable у вас данные остатков могут быть не корректны. И это зависит от реализации вычисления остатков. Если это просто поле в записи, то все будет ок. А вот если у вас это вычисляемое значение по нескольким записям, то вы получите фантомное чтение, когда не будет учтен добавленный в соседней транзакции остаток.
Для вычисляемых полей в 1С как раз и ставят при новом механизме блокировку, вручную, на те поля, которые влияют на остаток. Но в последних конфигурациях количество таких мест сведено к минимуму, а в основном используется подход, описанный мной. И остатки там «просто поле в записи», точнее в нескольких записях в одной таблице, и этот подход позволяет повысить параллельность работы пользователей.
Вобщем, мой вывод такой, что, реализовать всё можно. Но поведение в разных СУБД будет несколько отличаться, и 1С решили что проще сделать новый
Спасибо за конструктивный диалог.
Тогда нельзя будет откатить изменения, не влияющие на остаток, которые записаны до открытия транзакции.
Вот если повысить уровень изоляции — то да, сработает. Но не в курсе, возможно ли такое.
Естественно.
Для вычисляемых полей в 1С как раз и ставят при новом механизме блокировку, вручную, на те поля, которые влияют на остаток. Но в последних конфигурациях количество таких мест сведено к минимуму, а в основном используется подход, описанный мной. И остатки там «просто поле в записи», точнее в нескольких записях в одной таблице, и этот подход позволяет повысить параллельность работы пользователей.
В таком случае read commited будет работать лучше. Что хорошо для производительности.
Вобщем, мой вывод такой, что, реализовать всё можно. Но поведение в разных СУБД будет несколько отличаться, и 1С решили что проще сделать новый велосипед механизм, чем учитывать эти различия.
Прикол в том что уровни изоляции не различаются у РСУБД ибо стандарт :)
5.4 и 5.5 вроде как решаются через механизм сравнения-объединения конфигураций (весьма гибкая штука, но интерфейс первое время приводит в ужас)
5.6 решена только для отчетов на СКД
Все вышесказанное относится к 1С 8.2 и выше.
А вот остальные — да, присоединяюсь. Особенно к 5.1 и 5.7
5.6 решена только для отчетов на СКД
Все вышесказанное относится к 1С 8.2 и выше.
А вот остальные — да, присоединяюсь. Особенно к 5.1 и 5.7
Возможность разработки… на русском и английском языках
Зачем?
Одной из проблем программирования в 1С является код вида:
// Изменения Антона
...
// Конец изменений Антона
Там вообще возможно подключить систему контроля версий?
Возможно, но этим очень редко пользуются.
Там есть свой ее аналог — хранилище конфигурации.
О существовании этого аналога знает и пользует 5% программистов 1С. Как то пришлось глянуть исходники конфигурации. Комментариев, описывающих автора изменений больше, чем кода (утрирую).
Охотно верю, к сожалению. Ну, может, не 5%, но 10.
С другой стороны, у нас хранилище используют на каждом сколько-нибудь крупном проекте (по сути, в любом, над которым работает больше 3-5 человек, в зависимости от степени пересечения их областей ответственности), так что, возвращаясь к моему комменту, это не 1С хреновая, а данные конкретные 1С-ники.
С другой стороны, у нас хранилище используют на каждом сколько-нибудь крупном проекте (по сути, в любом, над которым работает больше 3-5 человек, в зависимости от степени пересечения их областей ответственности), так что, возвращаясь к моему комменту, это не 1С хреновая, а данные конкретные 1С-ники.
А Битрикс причем? Это совсем другой продукт ничего общего не имеющий с 1С. Это даже другая компания. С тем же успехом можно было статью засунуть в хаб Магенты например
Астрологи объявили неделю 1С на хабре. Популяция внешних отчетов и обработок выросла.
Одним из заблуждений является то, что хороший программист 1С должен знать бухгалтерию.
Меня убеждали в обратном. У меня есть двое знакомых сертифицированных специалистов 1С и оба они утверждают, что во время их подготовки большая часть времени уделялась именно бухгалтерии. Что, как и откуда берется и что потом с этим делать. Очень часто из за ошибок в самой 1C в расчеты закрадываются ошибки и чтобы эти ошибки исправить корректно недостаточно быть только программистом — нужно быть еще и бухгалтером. Еще очень часто, даже главные бухгалтеры, знают что должно получится, но не могут объяснить как этого добиться. Но всё это со слов моих товарищей.
Какой это уже по счету хабра\1с\суицид?
С какого раза дойдет что не стоит создавать отдельные топики для показа своих 5ти копеек на эту тему.?
С какого раза дойдет что не стоит создавать отдельные топики для показа своих 5ти копеек на эту тему.?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему 1С — это хорошо