Поэтому а)менять спецификатор доступа не рекомендуется б)в C# был введен модификатор override, который вводит ясность в то, переопределили ли вы что-нибудь, или нет )
А вообще вам советую пользоваться аннотацией @Override, если есть возможность — компилятор сразу подскажет, что не так.
HQL — корпоративный стандарт в мире Java (кроме Hibernate, как минимум TopLink и EclipseLink его поддерживают).
На что конкретно вам смотреть, не могу сказать, потому что не очень хорошо представляю, что вы хотите найти; но вот тут в блоге code-inside-out.blogspot.com/2009/01/25-ormapper.html перечислено то, что поддерживается в NHibernate и полезно иметь в ORM.
Не, не так ) Работу должен делать тот, кому назначили делать эту работу. У нас не Индия, каст нет. Если его моральные принципы запрещают ему заниматься этим, пусть меняет — либо принципы, либо работу.
Я техлид на совершенно другом проекте, на этом — только аудитор. А коммитов художника в проекте большая часть, потому что ведущий программист там — он.
Я уже написал ниже про «истинного» художника. Надеюсь, в своем изложении вы имели в виду именно его, а не летуна-белоручку.
Тестеры есть, но если бы он говорил, как улучшить процесс, я бы первый его поддержал :D
Но на практике почему-то оказывается, что он рапортует, что багов нет и все у него работает, потому что снизойти до unit-testing-а ему не позволяет я не знаю что, а найденные за ним баги отказывается фиксить с пометкой «отклонено, неинтересно» :D
Я же говорил, у нас разное понимание художника, видимо ) Тот тип художника, о котором я говорю, даже Doxygen-комментарии для публичного API считает рутиной :D
Нет, это Вы, наверное, путаете меня и менеджера проекта; уверяю, я только технический лидер, и к распределению задач, ресурсов и приоритетов, не имею ни малейшего отношения :)
Мне все равно, кому и что надоедает. Я в такой ситуации тоже не собираюсь выступать в роли Джамшута только потому, что кто-то капризничает громче, чем я:)
Вернее, так:
1. Джамшут меееедленно, печально и безынтересно прожует и выполнит работу;
2. «Художник» скажет «идите нах, моя гениальность не стоит того, чтобы тратить ее на то, чтобы проект заработал»;
3. Истинный художник возьмется за рутинную работу и выполнит ее; а за время, ушедшее на рутину, он постарается придумать, как сделать так, чтобы потребности в такой рутине больше не возникало — потом созовет всех в переговорную, и предложит обоснованные меры по увеличению эффективности.
P.S. Да и что такое «нормальную работу» художнику? Разве приведение проекта в приличное состояние — это не нормальная работа? Что еще надо вдобавок — пиво, девки, блэкджек?
Мы счас не стратегии мержа обсуждаем, а отношение «художников» к своей работе.
Проблема в том, что нет гарантии, что проект _внезапно_ не «разонравится» художнику, и тот вдарит по тапкам. Проект уже неинтересен, и делать его «художник» не будет.
Очень хорошо.
Давайте, я с вами соглашусь. Предположим, архитектор просчитался указанным образом — ну, с кем не бывает, от ошибок никто не застрахован ;)
Что делать дальше — смержить-то надо? 90% вероятности того, что художник закатит истерику «вот, вы меня не послушали, а теперь такая ж*па, и поэтому я не буду разгребать ваше гуано».
Как мне кажется, текстовая форма — это только одна из форм, причем не самая удачная (с точки зрения программиста). Хотя ее проработка может быть хорошим «трамплином», чтобы перейти к более общему пониманию формы и механизма запросов в репозиторий объектов.
Второе. В Hibernate есть все, что стоит иметь в хорошем ORM уровня Enterprise :) Совершенно необязательно переносить это все к себе, но кое-что иметь крайне полезно.
К сожалению, обсуждение этого выходит за рамки поста, потому как тут вы поднимали тему исключительно паттерна Query-Object.
Я думаю, что ваш путь с текстовым описанием будет куда сложнее. Оно вам надо? :)
Парсер «синтаксис -> AST», а затем AST-процессор — это не та штука, которую можно написать и забыть — как правило, это одна из самых сложно тестируемых частей. Даже у MS в ее T-SQL встречаются баги разбора SQL-команд.
Куда проще и понятнее Query Objects, которые позволяют строить AST напрямую, пользуясь возможностями самого языка программирования. Понятно, что для сложных запросов этот процесс будет выглядет монстровато, но на практике 90% — более-менее простые запросы.
Далее, Query Object может отлично скрыть за своим API манипуляции нижнего уровня, paging, самостоятельно оптимизировать запросы и т.п.
Я бы сначала пошел таким путем, а затем прикрутил к нему text query, если понадобилось бы, благо одно хорошо уживается с другим. Рекомендую вам посмотреть на HQL и Criteria API из Hibernate.
Тем не менее, решать-то вам :) В любом случае, удачи.
«за сокеты, ексель, так званую, за радостью, закупочка», да еще где есть.
Не удаляйте, пожалуйста: так душевнее, и сразу видно, что человек сам писал )
А вообще вам советую пользоваться аннотацией @Override, если есть возможность — компилятор сразу подскажет, что не так.
Обратите внимание на NHibenrate Criteria API
На что конкретно вам смотреть, не могу сказать, потому что не очень хорошо представляю, что вы хотите найти; но вот тут в блоге code-inside-out.blogspot.com/2009/01/25-ormapper.html перечислено то, что поддерживается в NHibernate и полезно иметь в ORM.
Я техлид на совершенно другом проекте, на этом — только аудитор. А коммитов художника в проекте большая часть, потому что ведущий программист там — он.
Я уже написал ниже про «истинного» художника. Надеюсь, в своем изложении вы имели в виду именно его, а не летуна-белоручку.
Но на практике почему-то оказывается, что он рапортует, что багов нет и все у него работает, потому что снизойти до unit-testing-а ему не позволяет я не знаю что, а найденные за ним баги отказывается фиксить с пометкой «отклонено, неинтересно» :D
Я же говорил, у нас разное понимание художника, видимо ) Тот тип художника, о котором я говорю, даже Doxygen-комментарии для публичного API считает рутиной :D
Вернее, так:
1. Джамшут меееедленно, печально и безынтересно прожует и выполнит работу;
2. «Художник» скажет «идите нах, моя гениальность не стоит того, чтобы тратить ее на то, чтобы проект заработал»;
3. Истинный художник возьмется за рутинную работу и выполнит ее; а за время, ушедшее на рутину, он постарается придумать, как сделать так, чтобы потребности в такой рутине больше не возникало — потом созовет всех в переговорную, и предложит обоснованные меры по увеличению эффективности.
P.S. Да и что такое «нормальную работу» художнику? Разве приведение проекта в приличное состояние — это не нормальная работа? Что еще надо вдобавок — пиво, девки, блэкджек?
А премию художнику выпишем обязательно. По печени, бгг :) Потому что тут работа, а не танцы «я то не хочу, это не буду».
Почему из-за его каприза кто-то другой должен этим заниматься (например, я)?
Проблема в том, что нет гарантии, что проект _внезапно_ не «разонравится» художнику, и тот вдарит по тапкам. Проект уже неинтересен, и делать его «художник» не будет.
Пример с мержем — просто иллюстратив, не более.
Давайте, я с вами соглашусь. Предположим, архитектор просчитался указанным образом — ну, с кем не бывает, от ошибок никто не застрахован ;)
Что делать дальше — смержить-то надо? 90% вероятности того, что художник закатит истерику «вот, вы меня не послушали, а теперь такая ж*па, и поэтому я не буду разгребать ваше гуано».
А смержить-то — все равно кому-то надо :-P
Что я делаю не так и как мне исправиться?
Второе. В Hibernate есть все, что стоит иметь в хорошем ORM уровня Enterprise :) Совершенно необязательно переносить это все к себе, но кое-что иметь крайне полезно.
К сожалению, обсуждение этого выходит за рамки поста, потому как тут вы поднимали тему исключительно паттерна Query-Object.
Спасибо за предметный разговор.
Парсер «синтаксис -> AST», а затем AST-процессор — это не та штука, которую можно написать и забыть — как правило, это одна из самых сложно тестируемых частей. Даже у MS в ее T-SQL встречаются баги разбора SQL-команд.
Куда проще и понятнее Query Objects, которые позволяют строить AST напрямую, пользуясь возможностями самого языка программирования. Понятно, что для сложных запросов этот процесс будет выглядет монстровато, но на практике 90% — более-менее простые запросы.
Далее, Query Object может отлично скрыть за своим API манипуляции нижнего уровня, paging, самостоятельно оптимизировать запросы и т.п.
Я бы сначала пошел таким путем, а затем прикрутил к нему text query, если понадобилось бы, благо одно хорошо уживается с другим. Рекомендую вам посмотреть на HQL и Criteria API из Hibernate.
Тем не менее, решать-то вам :) В любом случае, удачи.
Не удаляйте, пожалуйста: так душевнее, и сразу видно, что человек сам писал )