Дабы писать все единообразно
(
    select  $Спр.Код , $Спр.Наименование,$Спр.Единица
вместо текущего
    select  Спр.code,Спр.descr,$Спр.Единица
)

предлагаю добавить в парсер обработку таких выражений.
(те. для справоника выражения типа $Спр.Код заменять на Спр.code)

В принципе у меня есть вариант парсера, реализующего подстановки
"Код","Сode" -> "code"
"Наименование","Description" -> "descr"
"Родитель","Parent" -> "parentid"
"Владелец","Owner" -> "parentext"

Легко можно подобавлять и иные поля (типа ПометкаНаУдаление, ID),
надо только с их именем определиться.

Что народ (и разработчики) скажет по этому поводу?

ну это-то по моему решить можно...

но я все равно считаю также: поначалу действительно непривычно было, но пару месяцев написания кода и - нет проблем - большинство основных идентификаторов таблиц и полей я знаю, так что этот функционал далеко не обязателен, а то так совсем можно забыть "как там все устроено"

Единственный плюс - в зависимости от того: DBF, или SQL - нужно добавлять символ _ к наименованию таблиц, начинающихся с цифры, но так как запросы для разных сред далеко не всегда универсальны, то и эта фишка тут вряд ли сильно поможет

Мое предложение по расширению функционала парсера:
1) добавить все же виртуальные значения разных типов Справочник('B1'), Документ('O1') и т.д. - это используется редко, а потому напрочь забывается
2) ну и сделать таки типизацию видов документов(IDDOCDEF) в строковое выражение, так как они отображаются в конфигураторе - чтобы снять с повестки дня этот постоянно возникающий вопрос!  

"По странному стечению обстоятельств" у справочника вполне могут оказаться (пользовательские) реквизиты Родитель, Владелец, ... 

alexqc писал(а) 25. Августа 2006 :: 08:25:

Их можно сделать и в многоуровневом справочнике с владельцем. А как их 1С распознаёт - это уже другой вопрос. Важно, что в метапарсере это должно разруливаться. Если, конечно, там что-то будет в связи с этим меняться.

Ещё раз. Метапарсер должен однозначно, исходя из текста запроса, выбрать или системное поле или пользовательское. В предложенном варианте эта ситуация не разруливается.

На счёт надуманности проблемы: я тоже считал такие вещи маловероятными и не учитывал их в ранних версиях конструктора запросов. И мне пришлось изменить это мнение на основании реальных багрепортов.

Лично я не за такое расширение метапарсера. В смысле, что я не против такого усовершенствования, но и не за. Имхо, надумано это все.

berezdetsky писал(а) 25. Августа 2006 :: 09:05:


Да почему не разруливается-то? Есть польз. реквизит - используем его. Нет - используем системные. Т.е. ВСЕ работающие до этого запросы - так работающими и останутся. парсер строит текст запроса однозначно, исходя из исходного текста и конфигурации.

Цитата:

"Это не бага, это фича". такого рода места обычно документируются с указанием, что пользователь понимает что делает. А он действительно понимать должен - завтра 1С поменяет порядок поиска реквизитов, и у него все поплывет. Кстати, на счет владельца-родителя не знаю, но точно где-то в ЖКК (может, в метод. рекомендациях) наталкивался на примерно такую фразу - " не рекомендуется задавать измерению регитсра имя "Документ" ". И аналогично - никто не запрещает написать процедуру с системным именем ( Сообщить(), например ). Но если кто так сделает - какова интересно будет реакция на "У меня нифига не сообщает"?

alexqc писал(а) 25. Августа 2006 :: 09:31:


А когда, например, твой напарник, не использующий прямые запросы, добавит подобное поле в справочник, и у тебя "поплывут" все запросы - это тоже будет фича? И где будет твоё "разруливается"?

Это я к тому, что предлагаемый тобой функционал на самом деле не упрощает, а усложняет использование метапарсера. Т.е. - он не нужен. IMHO.

DrACe
+1

Цитата:

Речь не о напарнике, а о том, что в текущей реализации метапарсера эта проблема просто не возникнет. В отличие от.

А мысль интересная (на счет головы). Возьму на вооружение.

berezdetsky писал(а) 25. Августа 2006 :: 10:44:


Да ради Бога - не нравится (боитесь) - не пользуйтесь. А уж коли использовать хотите и такая ситуация возникнуть может - договаривайтесь с напарником об именовании реквизитов.

Я вот недавно с 1С++ 1.8.1.6 на 2.0 переполз - так условия вида

НекийРекв in ( select * from #ВремТаб),
     где ВремТаб через УложитьСписокОбъектов создана 

перестали работать по причине появления во ВремТаб еще одного поля. Ну так ничего - заменил * на val, никуда не делся. И считаю - именно это правильно. А тут - полная совместимость со старым кодом.

Ну и наконец, как вариант можно так сделать - можно в именах использовать знак # - т.е. $Спр.Код#. # распознается парсером как часть идентификатора (т.к. во врем. таблицах используется), и на обработку пойдет все имя "Код#". А таких имен в 1Ске точно не будет.

berezdetsky писал(а) 28. Августа 2006 :: 09:23:

За переопределение предопределенного имени . Если для этого есть какой-то смысл (ну например, стандартную обработку перекрыть) - тогда понятно. А если нет, просто так назвали - тогда нефиг. Польза от названия сомнительно, а геморрой гдето вылезти может, и не будешь знать с чего. Кстати, а 1Совский "Запрос" как с такими реквизитами работает, не проверяли? Или ОЛЕ?

Цитата:

Я бы не стал называть это "побочным действием". Все четко по заданному определению.

Заинтересовало.
В принципе, как и говорили предыдущие ораторы, пофиг, как написано Code или Код.
НО(!!!) для общего стиля написания АДНАЗНАЧНА лучше Код.

Посмотрите тот же Той-СКЛ. Нет там никаких Code, Desr и тр

Это пережить можно, вот еслиб удалось получить значения перечислений, причем для подключенной базы, вот это да, это я понимаю!
Чтоб

SELECT Code, Descr FROM $Справочник.Номенклатура AS S WHERE $S.ВидТовара=$Перечисление.ВидыТоваров.Услуга

Да, не заметил, огромной сенкс!