В идеале у вас должна быть обеспечена уникальность значений типа дата хотя бы в рамках информационной базы. Это соответствует тому, что мы имеем в реальном мире.
Если уникальность дат не обеспечена, тогда запрос будет возвращать несколько строк. Но это должны быть последние цены, а не как сейчас - тоже несколько строк, но не последние, а все подряд
С документацией у 1С все в порядке. Там про этот случай ничего не написано (!) Ну ха-ха же, нет?
Из нас двоих вы гораздо более "упертый". Я не делаю ОТБОР. В диалоге два раза сказал об этом. Давайте здесь еще раз повторю. Я не делаю ОТБОР.
Что касается индексов и производительности. Ну допустим, разработчики все предусмотрели и сделали быструю операцию для полного набора измерений. Для неполного набора быстрая операция невозможна. Ну и? Дальше-то что? Что с этим делать? Запрещать операцию? Делать хоть и медленную, но правильную? Ответ разработчиков 1С - а пусть будет неправильно, зато быстро. Это по-вашему разумно?
Ну подумайте сами. Смысл писать? Кто-то все равно будет введен в заблуждение, думая что механизм работает, как в РН. Надо не просто документацию исправлять, надо переделывать, вызывать сообщение об ошибке при выборе неполного набора измерений. А это, в свою очередь порождает вопрос: а не проще ли группировать правильно?
Не совсем так. Как они должны исправить документацию? Не делайте запрос по неполному набору измерений, потому что получите бессмысленный набор данных? И это при том, что переделать на правильный срез займет примерно столько же времени, что и переписывание документации
Конечно же я все внимательно слушаю. Более того, я подробно отвечаю на объяснения и показываю, чем они меня не устраивают. Иначе бы та ветка не была бы такой длинной.
Пожалуйста. Вот вам другой пример. Заказчик говорит иногда мне будут нужны последние документы продажи по контрагенту, иногда последние документы продажи по складу, а иногда последние документы продажи по сочетанию склад+контрагент. И что в этом случае следует делать? Создавать три регистра?
Но и обратное нигде не сказано. Вот дословная цитата из документации:
"Предназначена для получения наиболее поздних записей регистра сведений на указанную дату (включительно). Включает только активные записи. По каждой комбинации измерений будет найдена наиболее поздняя запись, но не более поздняя, чем указанная дата."
Только он забивает гвозди только 10 см. в длину. А 8 см. и 12 см. не забивает. Но называется молотком. И человек берет его в руки и ожидает, что его 12 см. гвоздь будет забит
Платформа и будет отвечать. Добавляешь к дате четыре байта и инкрементируешь
В статье подробно об этом написал.
В идеале у вас должна быть обеспечена уникальность значений типа дата хотя бы в рамках информационной базы. Это соответствует тому, что мы имеем в реальном мире.
Если уникальность дат не обеспечена, тогда запрос будет возвращать несколько строк. Но это должны быть последние цены, а не как сейчас - тоже несколько строк, но не последние, а все подряд
Вы сами себя прочтите медленно и внимательно.
С документацией у 1С все в порядке. Там про этот случай ничего не написано (!) Ну ха-ха же, нет?
Из нас двоих вы гораздо более "упертый". Я не делаю ОТБОР. В диалоге два раза сказал об этом. Давайте здесь еще раз повторю. Я не делаю ОТБОР.
Что касается индексов и производительности. Ну допустим, разработчики все предусмотрели и сделали быструю операцию для полного набора измерений. Для неполного набора быстрая операция невозможна. Ну и? Дальше-то что? Что с этим делать? Запрещать операцию? Делать хоть и медленную, но правильную? Ответ разработчиков 1С - а пусть будет неправильно, зато быстро. Это по-вашему разумно?
Вы полагаете, что тех, кого что-то не устраивает в 1С, доли процентов?
Нет. У меня претензия именно к платформе. Я хочу, чтобы если таблицу назвали срезом последних, мне последние записи и выдавали
Так было бы, если бы 1С сделала срез правильно. Но сейчас запрос вернет и 19 и 20 и 21 год как последние записи. В этом и проблема
Ну подумайте сами. Смысл писать? Кто-то все равно будет введен в заблуждение, думая что механизм работает, как в РН. Надо не просто документацию исправлять, надо переделывать, вызывать сообщение об ошибке при выборе неполного набора измерений. А это, в свою очередь порождает вопрос: а не проще ли группировать правильно?
Не совсем так. Как они должны исправить документацию? Не делайте запрос по неполному набору измерений, потому что получите бессмысленный набор данных? И это при том, что переделать на правильный срез займет примерно столько же времени, что и переписывание документации
И часто вы таким образом меняете типовые конфигурации ради одного отчета?
Не могли бы пояснить: что именно я, по-вашему, не понимаю?
Конечно же я все внимательно слушаю. Более того, я подробно отвечаю на объяснения и показываю, чем они меня не устраивают. Иначе бы та ветка не была бы такой длинной.
Пожалуйста. Вот вам другой пример. Заказчик говорит иногда мне будут нужны последние документы продажи по контрагенту, иногда последние документы продажи по складу, а иногда последние документы продажи по сочетанию склад+контрагент. И что в этом случае следует делать? Создавать три регистра?
Получение последней цены товара из регистра сведений, где есть два измерения - это реальный кейс. Для наглядности. Вот исходные данные:
01.01.1990, ООО Ромашка, Ложка, 3 руб.
01.01.2021, ООО Василек, Ложка, 120 руб.
01.02.2021, ООО Василек, Ложка, 122 руб.
Так вот. Я хочу в результате запроса к срезу ПОСЛЕДНИХ получить:
01.02.2021, Ложка, 122 руб.
И я не хочу получать:
01.01.1990, Ложка, 3 руб.
01.02.2021, Ложка, 122 руб.
Потому что запись от 1990 года не относится к категории ПОСЛЕДНИХ. Это - просто ненужное старье
Там нет никакой логики, а есть просто небрежность.
Я хочу получать последние записи. И я не хочу получать бессмыслицу в результате запроса.
Но и обратное нигде не сказано. Вот дословная цитата из документации:
"Предназначена для получения наиболее поздних записей регистра сведений на указанную дату (включительно). Включает только активные записи. По каждой комбинации измерений будет найдена наиболее поздняя запись, но не более поздняя, чем указанная дата."
Что странного в том, чтобы ожидать что срез последних будет выдавать последние записи, а не все подряд?
Вы неверно поняли суть. Перечитайте статью, она короткая.
Как получить:
01.08.2021, Ложка, 190 р.
01.08.2021, Вилка, 155 р.
01.08.2021, Ложка, 191 р.
из:
01.01.2019, ООО Ромашка, Ложка, 150 р.
01.02.2019, ООО Ромашка, Вилка, 120 р.
01.03.2019, ООО Ромашка, Вилка, 125 р.
01.02.2020, ООО Незабудка, Ложка, 165 р.
01.03.2020, ООО Незабудка, Ложка, 167 р.
01.08.2021, ООО Василек, Ложка, 190 р.
01.08.2021, ООО Василек, Вилка, 155 р.
01.08.2021, ООО Одуванчик, Ложка, 191 р.
?
Нет, вы ошиблись. В объектной модели вообще нет возможности получить срез по неполному набору измерений.
Только он забивает гвозди только 10 см. в длину. А 8 см. и 12 см. не забивает. Но называется молотком. И человек берет его в руки и ожидает, что его 12 см. гвоздь будет забит