Package org.hibernate.dialect

Class Teradata14Dialect

    • Constructor Detail

      • Teradata14Dialect

        public Teradata14Dialect()

    • Method Detail

      • getAddColumnString

        public String getAddColumnString()
        Description copied from class: Dialect
        The syntax used to add a column to a table (optional).
        Overrides:
        getAddColumnString in class TeradataDialect
        Returns:
        The "add column" fragment.

      • getTypeName

        public String getTypeName​(int code,
                          int length,
                          int precision,
                          int scale)
                   throws HibernateException
        Get the name of the database type associated with the given java.sql.Types typecode.
        Overrides:
        getTypeName in class TeradataDialect
        Parameters:
        code - java.sql.Types typecode
        length - the length or precision of the column
        precision - the precision of the column
        scale - the scale of the column
        Returns:
        the database type name
        Throws:
        HibernateException

      • areStringComparisonsCaseInsensitive

        public boolean areStringComparisonsCaseInsensitive()
        Description copied from class: Dialect
        Are string comparisons implicitly case insensitive.

        In other words, does [where 'XYZ' = 'xyz'] resolve to true?

        Overrides:
        areStringComparisonsCaseInsensitive in class TeradataDialect
        Returns:
        True if comparisons are case insensitive.

      • supportsExpectedLobUsagePattern

        public boolean supportsExpectedLobUsagePattern()
        Description copied from class: Dialect
        Expected LOB usage pattern is such that I can perform an insert via prepared statement with a parameter binding for a LOB value without crazy casting to JDBC driver implementation-specific classes...

        Part of the trickiness here is the fact that this is largely driver dependent. For example, Oracle (which is notoriously bad with LOB support in their drivers historically) actually does a pretty good job with LOB support as of the 10.2.x versions of their drivers...

        Overrides:
        supportsExpectedLobUsagePattern in class Dialect
        Returns:
        True if normal LOB usage patterns can be used with this driver; false if driver-specific hookiness needs to be applied.

      • supportsTupleDistinctCounts

        public boolean supportsTupleDistinctCounts()
        Description copied from class: Dialect
        Does this dialect support `count(distinct a,b)`?
        Overrides:
        supportsTupleDistinctCounts in class Dialect
        Returns:
        True if the database supports counting distinct tuples; false otherwise.

      • supportsExistsInSelect

        public boolean supportsExistsInSelect()
        Description copied from class: Dialect
        Does the dialect support an exists statement in the select clause?
        Overrides:
        supportsExistsInSelect in class Dialect
        Returns:
        True if exists checks are allowed in the select clause; false otherwise.

      • supportsUnboundedLobLocatorMaterialization

        public boolean supportsUnboundedLobLocatorMaterialization()
        Description copied from class: Dialect
        Is it supported to materialize a LOB locator outside the transaction in which it was created?

        Again, part of the trickiness here is the fact that this is largely driver dependent.

        NOTE: all database I have tested which Dialect.supportsExpectedLobUsagePattern() also support the ability to materialize a LOB outside the owning transaction...

        Overrides:
        supportsUnboundedLobLocatorMaterialization in class Dialect
        Returns:
        True if unbounded materialization is supported; false otherwise.

      • registerResultSetOutParameter

        public int registerResultSetOutParameter​(CallableStatement statement,
                                         int col)
                                  throws SQLException
        Description copied from class: Dialect
        Registers a parameter (either OUT, or the new REF_CURSOR param type available in Java 8) capable of returning ResultSet *by position*. Pre-Java 8, registering such ResultSet-returning parameters varied greatly across database and drivers; hence its inclusion as part of the Dialect contract.
        Overrides:
        registerResultSetOutParameter in class Dialect
        Parameters:
        statement - The callable statement.
        col - The bind position at which to register the output param.
        Returns:
        The number of (contiguous) bind positions used.
        Throws:
        SQLException - Indicates problems registering the param.

      • getWriteLockString

        public String getWriteLockString​(int timeout)
        Description copied from class: Dialect
        Get the string to append to SELECT statements to acquire WRITE locks for this dialect. Location of the returned string is treated the same as getForUpdateString.
        Overrides:
        getWriteLockString in class Dialect
        Parameters:
        timeout - in milliseconds, -1 for indefinite wait and 0 for no wait.
        Returns:
        The appropriate LOCK clause string.

      • getReadLockString

        public String getReadLockString​(int timeout)
        Description copied from class: Dialect
        Get the string to append to SELECT statements to acquire READ locks for this dialect. Location of the returned string is treated the same as getForUpdateString.
        Overrides:
        getReadLockString in class Dialect
        Parameters:
        timeout - in milliseconds, -1 for indefinite wait and 0 for no wait.
        Returns:
        The appropriate LOCK clause string.

      • applyLocksToSql

        public String applyLocksToSql​(String sql,
                              LockOptions aliasedLockOptions,
                              Map keyColumnNames)
        Description copied from class: Dialect
        Modifies the given SQL by applying the appropriate updates for the specified lock modes and key columns.

        The behavior here is that of an ANSI SQL SELECT FOR UPDATE. This method is really intended to allow dialects which do not support SELECT FOR UPDATE to achieve this in their own fashion.

        Overrides:
        applyLocksToSql in class Dialect
        Parameters:
        sql - the SQL string to modify
        aliasedLockOptions - lock options indexed by aliased table names.
        keyColumnNames - a map of key columns indexed by aliased table names.
        Returns:
        the modified SQL string.

      • useFollowOnLocking

        public boolean useFollowOnLocking​(QueryParameters parameters)
        Description copied from class: Dialect
        Some dialects have trouble applying pessimistic locking depending upon what other query options are specified (paging, ordering, etc). This method allows these dialects to request that locking be applied by subsequent selects.
        Overrides:
        useFollowOnLocking in class Dialect
        Parameters:
        parameters - query parameters
        Returns:
        true indicates that the dialect requests that locking be applied by subsequent select; false (the default) indicates that locking should be applied to the main SQL statement..

      • supportsLockTimeouts

        public boolean supportsLockTimeouts()
        Description copied from class: Dialect
        Informational metadata about whether this dialect is known to support specifying timeouts for requested lock acquisitions.
        Overrides:
        supportsLockTimeouts in class Dialect
        Returns:
        True is this dialect supports specifying lock timeouts.