Срез последних не выдает последние записи. И это не обставлено сообщением об ошибке и не описано в документации. Вы просто получаете неверный результат. Если хотите опровергнуть - аргументируйте, пожалуйста
Есть ошибки разной степени "опасности". Те, которые вы с высокой долей вероятности увидите сразу не опасны. Но есть и такие, которые могут "проскользнуть". Ошибка, которую провоцируют разработчики, как раз очень опасная. В моем кейсе элементарно можно было получить на реальных данных картинку неотличимую от нормальной работы среза последних. И только потом когда-нибудь получить претензию от клиента
Регистр сведений должен работать правильно. Вы понимаете разницу между не работает и работает не правильно?
Да, я в результате решаю задачу другим путем. Но я потратил время. А также у меня был риск сдать работу заказчику с ошибкой, потому что у разработчиков с логикой проблемы, а документация вводит в заблуждение
Нормально. Если ты хочешь впихнуть в одну секунду миллион документов, а система сама заботится о том, чтобы они встали в некотором порядке. Почему нет? Если тебе важен порядок, тогда сам его задаешь. Тут нет никаких проблем
Смотрите. Есть виртуальная таблица. Называется "Срез последних". В соответствии с названием, мы ожидаем, что она вернет последние записи. И это, и только это, надо считать правильной работой. Однако, оказывается, что если вы укажете в запросе неполный набор измерений, вы получите в результате не последние записи. Вы не получите сообщение об ошибке. Вам не скажут: "Ей, парень, это так не работает! Нужен полный набор измерений". Вам просто выдается неправильный результат. Документация написана так, что можно понять, как угодно. Лично меня это задевает еще и потому, что я прекрасно представляю, как это устроено внутри. Вы все равно так или иначе транслируете исходный запрос в SQL запрос. И вы все равно формируете список полей для группировки. Сделать так, чтобы в список для группировки попадало только то, что есть в исходном запросе - это вопрос одного "если". Проще может быть только замена значения константы. И да, меня злит то, что разработчики нашли время на никому не нужный срез первых и не нашли время на это "если". И еще, я, так же, как вы, пытаюсь понять - что движет теми, кто пытается любыми способами защитить разработчиков, даже в такой очевидной ситуации
Что я допускаю, что разработчики не были знакомы с теорией баз данных?
Или что они как дети малые бросили все как есть, вместо того чтобы доделать?
Первое, согласен, домысел. А вот второе - это факт данный нам в ощущениях.
У вас странная логика. Если операция 237065122+486369458 встречается довольно редко (а ведь так оно и есть), то нет ничего страшного в том, что результат не 723434580, а 876222544.
Во-первых, реальный кейс, который побудил меня написать статью, был на типовой конфигурации. А менять типовую конфигурацию ради одного отчета неразумно.
Во-вторых, если у вас два измерения, тогда вам надо будет создать три регистра, чтобы покрыть все возможные случаи. Если три измерения, тогда регистров будет шесть. А для четырех измерений потребуется уже 13 регистров. Вы уверены, что это правильный путь, вместо того чтобы убрать всего лишь одно (2,3) лишнее поле из группировки?
В идеале у вас должна быть обеспечена уникальность значений типа дата хотя бы в рамках информационной базы. Это соответствует тому, что мы имеем в реальном мире.
Если уникальность дат не обеспечена, тогда запрос будет возвращать несколько строк. Но это должны быть последние цены, а не как сейчас - тоже несколько строк, но не последние, а все подряд
С документацией у 1С все в порядке. Там про этот случай ничего не написано (!) Ну ха-ха же, нет?
Из нас двоих вы гораздо более "упертый". Я не делаю ОТБОР. В диалоге два раза сказал об этом. Давайте здесь еще раз повторю. Я не делаю ОТБОР.
Что касается индексов и производительности. Ну допустим, разработчики все предусмотрели и сделали быструю операцию для полного набора измерений. Для неполного набора быстрая операция невозможна. Ну и? Дальше-то что? Что с этим делать? Запрещать операцию? Делать хоть и медленную, но правильную? Ответ разработчиков 1С - а пусть будет неправильно, зато быстро. Это по-вашему разумно?
Ну подумайте сами. Смысл писать? Кто-то все равно будет введен в заблуждение, думая что механизм работает, как в РН. Надо не просто документацию исправлять, надо переделывать, вызывать сообщение об ошибке при выборе неполного набора измерений. А это, в свою очередь порождает вопрос: а не проще ли группировать правильно?
Не совсем так. Как они должны исправить документацию? Не делайте запрос по неполному набору измерений, потому что получите бессмысленный набор данных? И это при том, что переделать на правильный срез займет примерно столько же времени, что и переписывание документации
К Чистову? Спасибо, я пока подожду
Хоть записей, хоть значений. Выше я уже приводил пример
01.02.2021, Ложка, 122 руб.
Это последние записи
01.01.1990, Ложка, 3 руб.
01.02.2021, Ложка, 122 руб.
А это - не последние записи. Разве не очевидно?
А почему бы не сделать платформу так, чтобы белиберда не получалась?
Срез последних не выдает последние записи. И это не обставлено сообщением об ошибке и не описано в документации. Вы просто получаете неверный результат. Если хотите опровергнуть - аргументируйте, пожалуйста
Есть ошибки разной степени "опасности". Те, которые вы с высокой долей вероятности увидите сразу не опасны. Но есть и такие, которые могут "проскользнуть". Ошибка, которую провоцируют разработчики, как раз очень опасная. В моем кейсе элементарно можно было получить на реальных данных картинку неотличимую от нормальной работы среза последних. И только потом когда-нибудь получить претензию от клиента
Потому что "много людей"? У вас другие аргументы есть?
Регистр сведений должен работать правильно. Вы понимаете разницу между не работает и работает не правильно?
Да, я в результате решаю задачу другим путем. Но я потратил время. А также у меня был риск сдать работу заказчику с ошибкой, потому что у разработчиков с логикой проблемы, а документация вводит в заблуждение
Нормально. Если ты хочешь впихнуть в одну секунду миллион документов, а система сама заботится о том, чтобы они встали в некотором порядке. Почему нет? Если тебе важен порядок, тогда сам его задаешь. Тут нет никаких проблем
Только до того момента, когда вы попытаетесь выполнить запрос по неполному набору измерений. Тут-то эта уникальность и пропадает с концами
Смотрите. Есть виртуальная таблица. Называется "Срез последних". В соответствии с названием, мы ожидаем, что она вернет последние записи. И это, и только это, надо считать правильной работой. Однако, оказывается, что если вы укажете в запросе неполный набор измерений, вы получите в результате не последние записи. Вы не получите сообщение об ошибке. Вам не скажут: "Ей, парень, это так не работает! Нужен полный набор измерений". Вам просто выдается неправильный результат. Документация написана так, что можно понять, как угодно. Лично меня это задевает еще и потому, что я прекрасно представляю, как это устроено внутри. Вы все равно так или иначе транслируете исходный запрос в SQL запрос. И вы все равно формируете список полей для группировки. Сделать так, чтобы в список для группировки попадало только то, что есть в исходном запросе - это вопрос одного "если". Проще может быть только замена значения константы. И да, меня злит то, что разработчики нашли время на никому не нужный срез первых и не нашли время на это "если". И еще, я, так же, как вы, пытаюсь понять - что движет теми, кто пытается любыми способами защитить разработчиков, даже в такой очевидной ситуации
Что вы называете домыслами? Конкретно?
Что я допускаю, что разработчики не были знакомы с теорией баз данных?
Или что они как дети малые бросили все как есть, вместо того чтобы доделать?
Первое, согласен, домысел. А вот второе - это факт данный нам в ощущениях.
У вас странная логика. Если операция 237065122+486369458 встречается довольно редко (а ведь так оно и есть), то нет ничего страшного в том, что результат не 723434580, а 876222544.
Во-первых, реальный кейс, который побудил меня написать статью, был на типовой конфигурации. А менять типовую конфигурацию ради одного отчета неразумно.
Во-вторых, если у вас два измерения, тогда вам надо будет создать три регистра, чтобы покрыть все возможные случаи. Если три измерения, тогда регистров будет шесть. А для четырех измерений потребуется уже 13 регистров. Вы уверены, что это правильный путь, вместо того чтобы убрать всего лишь одно (2,3) лишнее поле из группировки?
Ничего не делать. Бери любую, любая годится
Платформа и будет отвечать. Добавляешь к дате четыре байта и инкрементируешь
В статье подробно об этом написал.
В идеале у вас должна быть обеспечена уникальность значений типа дата хотя бы в рамках информационной базы. Это соответствует тому, что мы имеем в реальном мире.
Если уникальность дат не обеспечена, тогда запрос будет возвращать несколько строк. Но это должны быть последние цены, а не как сейчас - тоже несколько строк, но не последние, а все подряд
Вы сами себя прочтите медленно и внимательно.
С документацией у 1С все в порядке. Там про этот случай ничего не написано (!) Ну ха-ха же, нет?
Из нас двоих вы гораздо более "упертый". Я не делаю ОТБОР. В диалоге два раза сказал об этом. Давайте здесь еще раз повторю. Я не делаю ОТБОР.
Что касается индексов и производительности. Ну допустим, разработчики все предусмотрели и сделали быструю операцию для полного набора измерений. Для неполного набора быстрая операция невозможна. Ну и? Дальше-то что? Что с этим делать? Запрещать операцию? Делать хоть и медленную, но правильную? Ответ разработчиков 1С - а пусть будет неправильно, зато быстро. Это по-вашему разумно?
Вы полагаете, что тех, кого что-то не устраивает в 1С, доли процентов?
Нет. У меня претензия именно к платформе. Я хочу, чтобы если таблицу назвали срезом последних, мне последние записи и выдавали
Так было бы, если бы 1С сделала срез правильно. Но сейчас запрос вернет и 19 и 20 и 21 год как последние записи. В этом и проблема
Ну подумайте сами. Смысл писать? Кто-то все равно будет введен в заблуждение, думая что механизм работает, как в РН. Надо не просто документацию исправлять, надо переделывать, вызывать сообщение об ошибке при выборе неполного набора измерений. А это, в свою очередь порождает вопрос: а не проще ли группировать правильно?
Не совсем так. Как они должны исправить документацию? Не делайте запрос по неполному набору измерений, потому что получите бессмысленный набор данных? И это при том, что переделать на правильный срез займет примерно столько же времени, что и переписывание документации