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

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