com.smartgwt.client.types

## Enum TextMatchStyle

- java.lang.Object
- - java.lang.Enum<TextMatchStyle>
  - - com.smartgwt.client.types.TextMatchStyle

- All Implemented Interfaces:
    ValueEnum, java.io.Serializable, java.lang.Comparable<TextMatchStyle>

      public enum TextMatchStyle
      extends java.lang.Enum<TextMatchStyle>
      implements ValueEnum

  For "fetch" operations, how simple search criteria should be interpreted for text fields (and to some extent numeric fields, see the notes below). For greater flexibility, use `AdvancedCriteria`.

- - ### Enum Constant Summary

    Enum Constants
    Enum Constant and Description
    `EXACT` case-insensitive exact match ("foo" matches "foo" and "FoO", but not "FooBar")
    `EXACT_CASE` case-sensitive exact match ("foo" matches only "foo")
    `STARTS_WITH` case-insensitive prefix match ("foo" matches "FooBar" but not "BarFoo")
    `SUBSTRING` case-insenstive substring match ("foo" matches "foobar" and "BarFoo")

  - ### Method Summary

    All Methods Static Methods Instance Methods Concrete Methods
    Modifier and Type | Method and Description
    --- | ---
    `java.lang.String` | `getValue()`
    `static TextMatchStyle` | `valueOf(java.lang.String name)` Returns the enum constant of this type with the specified name.
    `static TextMatchStyle[]` | `values()` Returns an array containing the constants of this enum type, in the order they are declared.

    - ### Methods inherited from class java.lang.Enum

      `clone, compareTo, equals, finalize, getDeclaringClass, hashCode, name, ordinal, toString, valueOf`

    - ### Methods inherited from class java.lang.Object

      `getClass, notify, notifyAll, wait, wait, wait`

- - ### Enum Constant Detail

    - #### EXACT

          public static final TextMatchStyle EXACT

      case-insensitive exact match ("foo" matches "foo" and "FoO", but not "FooBar")

      If this enumerated value is used in a `Component XML` file or server-side DataSource descriptor (.ds.xml file), use the value "exact".

    - #### EXACT_CASE

          public static final TextMatchStyle EXACT_CASE

      case-sensitive exact match ("foo" matches only "foo")

      If this enumerated value is used in a `Component XML` file or server-side DataSource descriptor (.ds.xml file), use the value "exactCase".

    - #### SUBSTRING

          public static final TextMatchStyle SUBSTRING

      case-insenstive substring match ("foo" matches "foobar" and "BarFoo")

      If this enumerated value is used in a `Component XML` file or server-side DataSource descriptor (.ds.xml file), use the value "substring".

    - #### STARTS_WITH

          public static final TextMatchStyle STARTS_WITH

      case-insensitive prefix match ("foo" matches "FooBar" but not "BarFoo")

      textMatchStyle behavior is consistent across the client and all three of the built-in server DataSource implementations - SQL, Hibernate and JPA - to the maximum extent that is practical. Known inconsistencies, some of which can be tweaked with configuration settings, are described below

      - textMatchStyle can be disabled for any individual field with the `DataSourceField.ignoreTextMatchStyle` declaration. This behavior is consistent across client and server implementations, with the proviso that case-sensitive behavior is inherently inconsistent in the server-side implementations (see below for a more detailed discussion of this)
      - textMatchStyle is forced to "exactCase" for `primaryKey` fields on `update` and `remove` operations, unless `OperationBinding.allowMultiUpdate` is in force. This means that a normal update or remove operation - which is constrained by a unique primaryKey value or combination, to affect only a single data row - will use an equality match on all primaryKey fields. This is desirable because it makes index usage more likely. Note that this means the key values "foo" and "FOO" are distinct, which is a change from previous behavior. For most databases, this change will have no effect because most databases do not by default allow primaryKey values that only differ in case anyway - if a table has a row with a PK of "foo" and you try to insert a row with a PK of "FOO", most databases will fail with a constraint violation. However, if you are using a database hat allows key values that differ only in case, and you need to support this for some reason, you can switch the framework back to the previous behavior by setting property `allow.case.sensitive.pks` to `true` in your `server.properties` file. Note, we do not recommend this; in fact, we do not recommend the use of text primaryKey fields at all. Where you have control ,we would always recommend the use of automatically incrementing numeric sequence keys.
      - textMatchStyle does not apply to boolean or temporal (date, datetime, time) `field types`. Such fields are always checked for equality. If you have a need for more complex matching, such as date-range checking, use AdvancedCriteria
      - Critiera values for temporal fields must be real dates (Javascript `Date` objects on the client, instances of `java.util.Date` on the server). Attempting to match against a string or any other type of value will result in an "always fails" clause being generated. This behavior is how the client code has always worked, but is a change for the server-side DataSources, in the interests of consistency. The previous behavior was:
        - SQLDataSource used to attempt to match the date column to the criteria value provided; if that value was an appropriately-formatted string, that attempt might have worked, but it would be database-specific. If you have an application that depends on this old behavior, you can switch it back on by adding the following to your `server.properties` file: `sql.temporal.fields.require.date.criteria: false`
        - HibernateDataSource and JPADataSource used to skip such clauses altogether, which results in the opposite behavior (there is an implied "always succeeds" clause, because the clause is not present in the query at all). If you have an application that depends on this old behavior, you can switch it back on by adding the following to your `server.properties` file: `jpa.temporal.fields.require.date.criteria: false` or `hibernate.temporal.fields.require.date.criteria: false`, as appropriate
      - textMatchStyle does not apply to fields used in the joins generated to satisfy `includeFrom` declarations or entity relations in Hibernate or JPA. Again, such comparisons are always for equality
      - textMatchStyle is applied to numeric fields only if the supplied criteria value is a string. So for a numeric field "myNumber", we will match 10, 100, 110 and 1000 if a criteria value of "10" (the quoted string) is supplied, but we will only match 10 if a criteria value of 10 (the actual number) is supplied
        - This is a change in behavior for the server-side DataSource implementations, in the interests of consistency with the client behavior. Previously, all three of the built-in DataSource implementations applied textMatchStyle to numeric fields regardless of the criteria value's type. If you have an application that depends on this old behavior, you can switch it back on by adding the following to your `server.properties` file: `sql.substring.numeric.criteria: true` or `hibernate.substring.numeric.criteria: true` or `jpa.substring.numeric.criteria: true`, as appropriate
      - "exactCase" matching cannot be made consistent across all database providers because each database has its own idea of whether case-sensitive matching should be the default, and how to switch it on and off (if that is even possible)
        - Microsoft SQL Server must have case-sensitive matching enabled by setting a case-sensitive collation when the database is created (there are more fine-grained options, but we do not recommend them because of the scope for further inconsistency, where "exactCase" works correctly on table A but not on table B). See MSDN for details
        - HSQLDB has case sensitivity set with the `SET IGNORECASE` directive - see here
        - MySQL is case-insensitive, but since it provides an easy way to do per-query, case-sensitive matching in SQL, we work around it for that database, but only in SQL DataSources
      - If you are using Hibernate or JPA, whether "exactCase" works as expected depends entirely on the underlying database. Unlike the SQL DataSource, where we have fine-grained control of the SQL that the database executes, we are constrained by what the ORM will allow. This prevents us from compensating for database quirks, like we do with MySQL's case-insensitivity in the SQL DataSource

      If this enumerated value is used in a `Component XML` file or server-side DataSource descriptor (.ds.xml file), use the value "startsWith".

  - ### Method Detail

    - #### values

          public static TextMatchStyle[] values()

      Returns an array containing the constants of this enum type, in the order they are declared. This method may be used to iterate over the constants as follows:

          for (TextMatchStyle c : TextMatchStyle.values())
              System.out.println(c);

      Returns:
        an array containing the constants of this enum type, in the order they are declared

    - #### valueOf

          public static TextMatchStyle valueOf(java.lang.String name)

      Returns the enum constant of this type with the specified name. The string must match exactly an identifier used to declare an enum constant in this type. (Extraneous whitespace characters are not permitted.)
      Parameters:
        `name` - the name of the enum constant to be returned.
      Returns:
        the enum constant with the specified name
      Throws:
        `java.lang.IllegalArgumentException` - if this enum type has no constant with the specified name
        `java.lang.NullPointerException` - if the argument is null

    - #### getValue

          public java.lang.String getValue()

      Specified by:
        `getValue` in interface `ValueEnum`