неправомерно рекламируемая информация размещалась в теле запроса авторизации. В Jabber нет такого понятия, как текст в запросе авторизации: отправляется лишь iq-запрос подписки на прием/получение презенсов (то есть статусов присутствия по сути) от конкретного контакта.
Спам можно размещать и в имени контакта, представьте себе.
Для динамического SQL, как указано в статье, будет использоваться другой синтаксис (a=new Query(); a.addSelect(); a.addFrom()), верно? Тут я согласен, что он удобнее, чем StringBuilder. Как построитель динамических запросов, Jooq найдет себе применение.
Я, заметьте, не говорил о разовой проверке. разумеется проверку нужно делать при каждой компиляции (или изменении запроса). Мы сравниваем способ хранения SQL кода внутри Java кода (или другого языка) — в текстовом или вот в таком виде.
Поддерживать сиквел нужно в любом случае. Разве такое представление запроса избавит от необходимости проверять глазками и копипастить в клиент БД? Ведь нужно не просто проверить синтаксис, а еще убедиться, что запрос
выполнится без ошибок
вернет правильный результат
выполнится с приемлемой производительностью
Сейчас сделать это, не покидая IDE возможности нет, (а должна быть наверное), значит нужно копипастить туда-сюда. Как это делать с данным представлением?
простое переименование колонки может обернуться головной болью
Верно. Как эта проблема решается в больших серьезных проектах? За запросы отвечают специиально обученные DB-разработчики, для которых родной язык — SQL. Как им работать с таким представлением? В статье приведены довольно примитивные примеры, а в реальных проектах запросы на 20+ строк и 5+ таблиц — обычное дело.
Это немало, само по себе. Только для этого не обязательно коверкать SQL синтаксис в нечто нечитабельное. Можно ведь взять SQL и скормить базе, она все проверит. В крайнем случае парсеру данного диалекта.
Но этого одного IMHO мало, чтобы перевесить все недостатки такого подхода.
Сам подход (и Jooq и аналоги) — что он дает? Только compile-time checking?
Зачем писать тот же SQL, только не на SQL? Я бы назвал это «обфусцированный SQL».
Уточните, все что на регэкспах, за парсер не считается?
Писал непарсер для trace-файлов от Oracle, на JS. Еще непарсер логов одной софтины (для профилирования), на awk. Все на регэкспах. Хотя контекст, например, присутствовал.
Вы пожаловаться пожаловались, а адекватный вариант действий для них не предложили. Их аргументы «почему так» вполне понятны, как и ваши «почему это плохо для меня». И если вы хотите изменить их бизнес-процесс, нужно что-то решить по каждому пункту.
Поддерживать сиквел нужно в любом случае. Разве такое представление запроса избавит от необходимости проверять глазками и копипастить в клиент БД? Ведь нужно не просто проверить синтаксис, а еще убедиться, что запрос
- выполнится без ошибок
- вернет правильный результат
- выполнится с приемлемой производительностью
Сейчас сделать это, не покидая IDE возможности нет, (а должна быть наверное), значит нужно копипастить туда-сюда. Как это делать с данным представлением?Верно. Как эта проблема решается в больших серьезных проектах? За запросы отвечают специиально обученные DB-разработчики, для которых родной язык — SQL. Как им работать с таким представлением? В статье приведены довольно примитивные примеры, а в реальных проектах запросы на 20+ строк и 5+ таблиц — обычное дело.
Но этого одного IMHO мало, чтобы перевесить все недостатки такого подхода.
Теперь еще Windows Phonе кто-нибудь распотрошите.
Зачем писать тот же SQL, только не на SQL? Я бы назвал это «обфусцированный SQL».
Надеюсь патент признают недействительным.
Силенок тоже хватит, другое дело, что в конечном счете это не поможет, так как глобализация уже неотвратима.
Почитайте кстати откровения моего тезки.
Писал непарсер для trace-файлов от Oracle, на JS. Еще непарсер логов одной софтины (для профилирования), на awk. Все на регэкспах. Хотя контекст, например, присутствовал.
Бесплатная утилизация это как вы понимаете расходы, причем пропорциональные скорее штукам, нежели граммам.