Как Вы пишете нечувствительный к регистру запрос и для MySQL и для Пост-ГРЭС?

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

См. также: A хороший список лучших практик

Я бы добавил, очень важно, хорошо использовать модификатор final. Использование "окончательной" модификатор, когда это применимо в Java

Сводка:

  1. Используйте модификатор final для обеспечения хорошей инициализации.
  2. Избегайте возврата null в методы, например, при возврате пустых коллекций.
  3. Использовать аннотации @NotNull и @Nullable
  4. Быстрое завершение работы и использование утверждений, чтобы избежать распространения нулевых объектов через все приложение, когда они не должен быть пустым.
  5. Сначала используйте значения с известным объектом: if("knownObject".equals(unknownObject)
  6. Предпочитают valueOf() поверх toString ().
  7. Используйте null safe StringUtils StringUtils.isEmpty(null).

64
задан cHao 10 June 2011 в 18:19
поделиться

6 ответов

select * from foo where upper(bar) = upper(?);

при установке параметра на верхний регистр в вызывающей стороне можно избежать второго вызова функции.

58
ответ дан Paul Tomblin 24 November 2019 в 15:38
поделиться

В пост-ГРЭС можно сделать это:

SELECT whatever FROM mytable WHERE something ILIKE 'match this';

я не уверен, существует ли эквивалент для MySQL, но можно всегда делать это, которое немного ужасно, но должно работать и в MySQL и в пост-ГРЭС:

SELECT whatever FROM mytable WHERE UPPER(something) = UPPER('match this');
13
ответ дан Adam Pierce 24 November 2019 в 15:38
поделиться

Преобразование в верхний является лучшим, поскольку оно покрывает совместимый синтаксис для 3 наиболее используемых бэкендов базы данных Rails. PostgreSQL, MySQL и SQLite вся поддержка этот синтаксис. Это имеет (незначительный) недостаток, что у Вас есть к верхнему регистру своя строка поиска в Вашем приложении или в Вашей строке условий, делая это немного более ужасным, но я думаю совместимость, которую Вы получаете, делает это worthwile.

И MySQL и SQLite3 имеют нечувствительный к регистру оператор LIKE. Только PostgreSQL имеет чувствительный к регистру оператор LIKE и PostgreSQL-определенное (на руководство) оператор ILIKE для поисков без учета регистра. Вы могли бы определить ILIKE insead ПОДОБНЫХ в Ваших условиях на приложении направляющих, но знать, что приложение прекратит работать под MySQL или SQLite.

опция трети А могла бы состоять в том, чтобы проверить, какой механизм базы данных Вы используете и изменяете строку поиска соответственно. Это могло бы быть лучше сделано путем взламывания / monkeypatching адаптеры соединения ActiveRecord и иметь адаптер PostgreSQL, изменяют строку запроса для замены "КАК" "ILIKE" до выполнения запросов. Это решение является однако самым замысловатым и в свете более легких путей как uppercasing оба условия, я думаю, что это не worh усилие (хотя Вы получили бы много одобрения для того, чтобы сделать его этот путь).

0
ответ дан 24 November 2019 в 15:38
поделиться

Мораль этой истории такова: не используйте другой программный стек для разработки и производства. Никогда.

Вы просто получите ошибки, которые не сможете воспроизвести в dev; ваше тестирование будет бесполезным. Только не делайте этого.

Об использовании другого механизма базы данных не может быть и речи - будет намного больше случаев, когда он будет вести себя иначе, чем просто LIKE (а также, проверяли ли вы сопоставления, используемые базами данных? идентичны во ВСЕМ СЛУЧАЕ? Если нет, то можете забыть ORDER BY для столбцов varchar, работающих одинаково)

73
ответ дан 24 November 2019 в 15:38
поделиться

Вы также можете попробовать плагин searchlogic , который выполняет за вас переключатель LIKE / ILIKE .

1
ответ дан 24 November 2019 в 15:38
поделиться

Если вы используете PostgreSQL 8.4, вы можете использовать citext модуль для создания текстовых полей без учета регистра.

2
ответ дан 24 November 2019 в 15:38
поделиться
Другие вопросы по тегам:

Похожие вопросы: