web-dev-qa-db-ja.com

JPA2：どこでも一致するように大文字と小文字を区別しない

JPA 1.0（Hibernateドライバー）でHibernate Restrictionsを使用しています。定義されたRestrictions.ilike("column","keyword", MatchMode.ANYWHERE)があります。これは、キーワードがどこかの列に一致し、大文字と小文字を区別しないかどうかをテストします。

現在、JPA 2.0をEclipseLinkとともにドライバーとして使用しているため、「制限」ビルドインJPA 2.0を使用する必要があります。 CriteriaBuilderとメソッドlikeを見つけましたが、どこでも一致させる方法を見つけました（それは恐ろしくて手作業ですが） -インセンシティブ。

私の現在の素晴らしい解決策があります：

CriteriaBuilder builder = em.getCriteriaBuilder();
CriteriaQuery<User> query = builder.createQuery(User.class);
EntityType<User> type = em.getMetamodel().entity(User.class);
Root<User> root = query.from(User.class);

// Where   
// important passage of code for question  
query.where(builder.or(builder.like(root.get(type.getDeclaredSingularAttribute("username", String.class)), "%" + keyword + "%"),
        builder.like(root.get(type.getDeclaredSingularAttribute("firstname", String.class)), "%" + keyword + "%"),
        builder.like(root.get(type.getDeclaredSingularAttribute("lastname", String.class)), "%" + keyword + "%")
        ));

// Order By
query.orderBy(builder.asc(root.get("lastname")),
            builder.asc(root.get("firstname")));

// Execute
return em.createQuery(query).
            setMaxResults(PAGE_SIZE + 1).
            setFirstResult((page - 1) * PAGE_SIZE).
            getResultList();

質問：

Hibernateドライバーのような機能はありますか？

JPA 2.0基準を正しく使用していますか？これは、Hibernate Restrictionsと比較すると厄介で不快なソリューションです。

または、大文字と小文字を区別しないようにソリューションを変更する方法を教えてください。

どうもありがとう。

javacriteriaeclipselinkjpa-2.0hibernate-criteria
46
Gaim

最初は少し厄介に思えるかもしれませんが、タイプセーフです。文字列からクエリを作成するのはそうではないため、コンパイル時ではなく実行時にエラーが発生します。 WHERE句全体を1行で記述する代わりに、インデントを使用するか、各ステップを個別に実行することにより、クエリを読みやすくすることができます。

クエリで大文字と小文字を区別しないようにするには、キーワードと比較フィールドの両方を小文字に変換します。

query.where(
    builder.or(
        builder.like(
            builder.lower(
                root.get(
                    type.getDeclaredSingularAttribute("username", String.class)
                )
            ), "%" + keyword.toLowerCase() + "%"
        ), 
        builder.like(
            builder.lower(
                root.get(
                    type.getDeclaredSingularAttribute("firstname", String.class)
                )
            ), "%" + keyword.toLowerCase() + "%"
        ), 
        builder.like(
            builder.lower(
                root.get(
                    type.getDeclaredSingularAttribute("lastname", String.class)
                )
            ), "%" + keyword.toLowerCase() + "%"
        )
    )
);
84
weltraumpirat

（現在）受け入れられている答えでコメントしたように、DBMSのlower()関数とJavaのString.toLowerCase()を使用する落とし穴があります。同じ入力文字列に対して同じ出力。

最終的に、リテラル式を使用してDBMSにすべての低下を行わせる、はるかに安全な（まだ防弾ではない）ソリューションを見つけました。

_builder.lower(builder.literal("%" + keyword + "%")
_

したがって、完全なソリューションは次のようになります。

_query.where(
    builder.or(
        builder.like(
            builder.lower(
                root.get(
                    type.getDeclaredSingularAttribute("username", String.class)
                )
            ), builder.lower(builder.literal("%" + keyword + "%")
        ), 
        builder.like(
            builder.lower(
                root.get(
                    type.getDeclaredSingularAttribute("firstname", String.class)
                )
            ), builder.lower(builder.literal("%" + keyword + "%")
        ), 
        builder.like(
            builder.lower(
                root.get(
                    type.getDeclaredSingularAttribute("lastname", String.class)
                )
            ), builder.lower(builder.literal("%" + keyword + "%")
        )
    )
);
_

編集：
@ cavpolloが例を挙げるように私に要求したので、私は自分の解決策について二度考えなければならず、受け入れられた答えよりもそれほど安全ではないことに気付きました。

_DB value* | keyword | accepted answer | my answer
------------------------------------------------
elie     | ELIE    | match           | match
Élie     | Élie    | no match        | match
Élie     | élie    | no match        | no match
élie     | Élie    | match           | no match
_

それでも、同じように機能するはずの2つの異なる関数の結果を比較しないため、私のソリューションを好みます。出力の比較がより「安定」するように、すべての文字配列にまったく同じ関数を適用します。

防弾ソリューションには、SQLのlower()がアクセント付き文字を正しく下げることができるようにロケールが含まれます。 （しかし、これは私の謙虚な知識を超えています）

*「C」ロケールのPostgreSQL 9.5.1でのDb値

9
Ghurdyl

私のためのこの仕事：

CriteriaBuilder critBuilder = em.getCriteriaBuilder();

CriteriaQuery<CtfLibrary> critQ = critBuilder.createQuery(Users.class);
Root<CtfLibrary> root = critQ.from(Users.class);

Expression<String> path = root.get("lastName");
Expression<String> upper =critBuilder.upper(path);
Predicate ctfPredicate = critBuilder.like(upper,"%stringToFind%")
critQ.where(critBuilder.and(ctfPredicate));
em.createQuery(critQ.select(root)).getResultList();
7
alpanko

JPAよりもデータベース内で大文字と小文字の区別を強制する方が簡単かつ効率的です。

  1. SQL 2003、2006、2008標準では、COLLATE SQL_Latin1_General_CP1_CI_AS OR COLLATE latin1_general_cs次へ：

    • 列の定義

      CREATE TABLE <table name> (
  <column name> <type name> [DEFAULT...] 
                            [NOT NULL|UNIQUE|PRIMARY KEY|REFERENCES...]
                            [COLLATE <collation name>], 
  ...
)

    • ドメイン定義

      CREATE DOMAIN <domain name> [ AS ] <data type>
  [ DEFAULT ... ] [ CHECK ... ] [ COLLATE <collation name> ]

    • 文字セットの定義

      CREATE CHARACTER SET <character set name>
[ AS ] GET <character set name> [ COLLATE <collation name> ]

    上記の詳細な説明については、 http://savage.net.au/SQL/sql-2003-2.bnf.html#column%20definitionhttp：//dev.mysql .com/doc/refman/5.1/en/charset-table.htmlhttp://msdn.Microsoft.com/en-us/library/ms184391.aspx

  2. Oracleでは、NLSセッション/構成パラメータを設定できます

     SQL> ALTER SESSION SET NLS_COMP=LINGUISTIC;
 SQL> ALTER SESSION SET NLS_SORT=BINARY_CI;
 SQL> SELECT ename FROM emp1 WHERE ename LIKE 'McC%e';

 ENAME
 ----------------------
 McCoye
 Mccathye

    または、init.ora（または初期化パラメーターファイルのOS固有の名前）：

    NLS_COMP=LINGUISTIC
NLS_SORT=BINARY_CI

    バイナリソートでは、大文字と小文字を区別しないか、アクセントを区別しないことができます。 NLS_SORTの値としてBINARY_CIを指定すると、アクセントを区別し、大文字と小文字を区別しない並べ替えが指定されます。 BINARY_AIは、アクセントを区別せず、大文字と小文字を区別しないバイナリソートを指定します。文字セットのバイナリソート順が使用している文字セットに適している場合は、バイナリソートを使用できます。 NLS_SORTセッションパラメータを使用して、大文字と小文字を区別しない、またはアクセントを区別しない並べ替えを指定します。

    Append _CI to a sort name for a case-insensitive sort.
Append _AI to a sort name for an accent-insensitive and case-insensitive sort.

    たとえば、NLS_SORTを次のタイプの値に設定できます。

    FRENCH_M_AI
XGERMAN_CI

    NLS_SORTを[オプションの_CIまたは_AIを使用する] BINARY以外に設定すると、オプティマイザーによって選択されたパスに関係なく、ソートで全表スキャンが使用されます。インデックスはキーのバイナリ順に従って構築されるため、BINARYは例外です。したがって、NLS_SORTがBINARYに設定されている場合、オプティマイザはインデックスを使用してORDER BY句を満たすことができます。 NLS_SORTが言語ソートに設定されている場合、オプティマイザーは実行計画に全表スキャンと全ソートを含める必要があります。

    または、上記のようにNLS_COMPがLINGUISTICに設定されている場合、データベース全体でグローバルにではなく、インデックス設定された列にローカルでソート設定を適用できます。

    CREATE INDEX emp_ci_index ON emp (NLSSORT(emp_name, 'NLS_SORT=BINARY_CI'));

    参照： ORA 11g言語ソートおよび文字列検索ORA 11gグローバリゼーションサポート環境のセットアップ

3
Glen Best

OpenJPA 2.3.0およびPostgresqlの絶望的な回避策

public class OpenJPAPostgresqlDictionaryPatch extends PostgresDictionary {

  @Override
  public SQLBuffer toOperation(String op, SQLBuffer selects, SQLBuffer from, SQLBuffer where, SQLBuffer group, SQLBuffer having, SQLBuffer order, boolean distinct, long start, long end, String forUpdateClause, boolean subselect) {
    String whereSQL = where.getSQL();
    int p = whereSQL.indexOf("LIKE");
    int offset = 0;
    while (p != -1) {
      where.replaceSqlString(p + offset, p + offset + 4, "ILIKE");
      p = whereSQL.indexOf("LIKE", p + 1);
      offset++;
    }
    return super.toOperation(op, selects, from, where, group, having, order, distinct, start, end, forUpdateClause, subselect);
  }

}

これは、OpenJPAおよびPostgresqlデータベースで大文字と小文字を区別しないLIKE操作を行うための脆弱でい回避策です。生成されたSQLのLIKE演算子をILIKE演算子に置き換えます。

OpenJPA DBDictionaryがオペレーター名を変更できないのは残念です。

1
mnesarco

使用することを検討してください

CriteriaBuilder.like(Expression<String> x, Expression<String> pattern, char escapeChar);

どこでもマッチングします。

0
Phuong Tran