Package com.smartgwt.client.types

# Enum CacheSyncTiming

java.lang.Object
java.lang.Enum<CacheSyncTiming>
com.smartgwt.client.types.CacheSyncTiming

All Implemented Interfaces:
  `ValueEnum`, `Serializable`, `Comparable<CacheSyncTiming>`, `Constable`

public enum CacheSyncTiming extends Enum<CacheSyncTiming> implements ValueEnum
Indicates the timing strategy to be used for `automatic cache synchronization`, for a given `DataSource`, `OperationBinding` or `DSRequest`. This property controls the "when" of cache synchronization; the "how" is controlled by `CacheSyncStrategy`.

NOTE: `CacheSyncTiming` is intended to allow applications to defer cache synchronization to the point where response data is actually requested; the primary aim of this is to avoid doing cache sync altogether in cases where the response data is never requested. There are some mainstream types of request where we know that the response data unequivocally is required, and for these requests a global default `CacheSyncTiming` will be overridden to "immediate" by Smart GWT because there is no point in deferring cache sync when we know for sure it will eventually be needed. Thus, cache sync will always run immediately regardless of the default `cacheSyncTiming` setting in these cases:

- Requests sent from a client
- Server-created requests that copy an `RPCManager` across from a client-originated request, either by specifying it in the `DSRequest` constructor, or by calling `dsRequest.setRPCManager()`

The above only applies to the global default `cacheSyncTiming`: a `cacheSyncTiming` set explicitly at the `DataSource`, `operation` or `request` level will usually be honored. However, even an explicit `cacheSyncTiming` setting on the DataSource, operation or request will be ignored in situations where it could break a framework feature if we honored it. These situations are:

- Requests where `automatic auditing` is in force
- Requests on a dataSource with one-to-many or many-to-many relations, where the update means that Smart GWT must update foreign keys on the related dataSources to maintain relation integrity

In both these cases, we cannot allow the cache sync to be deferred because it is possible that a deferred cache sync fetch would never be invoked - indeed, that is the whole point of allowing cache sync to be deferred - and in that case, key processes would fail to run.

- ## Nested Class Summary

  ## Nested classes/interfaces inherited from class java.lang.Enum

  `Enum.EnumDesc<E extends Enum<E>>`

- ## Enum Constant Summary

  Enum Constants
  Enum Constant
  Description
  `IMMEDIATE`
  Obtain cache sync values immediately after the update operation returns
  `LAZY`
  Defer running cache sync until the first time `getData()` is called on the server-side `DSResponse`.

- ## Method Summary

  Modifier and Type
  Method
  Description
  `String`
  `getValue()`
  `static CacheSyncTiming`
  `valueOf(String name)`
  Returns the enum constant of this type with the specified name.
  `static CacheSyncTiming[]`
  `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, describeConstable, equals, finalize, getDeclaringClass, hashCode, name, ordinal, toString, valueOf`

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

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

- ## Enum Constant Details

  - ### IMMEDIATE

    public static final CacheSyncTiming IMMEDIATE
    Obtain cache sync values immediately after the update operation returns

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

  - ### LAZY

    public static final CacheSyncTiming LAZY
    Defer running cache sync until the first time `getData()` is called on the server-side `DSResponse`. As described above, the point of deferring cache sync is to avoid running it at all in cases where nothing needs the response data (and thus nothing calls `getData()`). In addition to the above-listed cases where we know that cache sync is always going to be required, there are other cases where `getData()` will be called, even if your application code doesn't do so. Some examples:
    - If logging levels are set such that the framework is logging response data
    - If you have a `multiple` field in your dataSource and its value requires transformation because of `multipleStorage` or `transformMultipleFields` settings
    In these cases, and others where the response data is required, the cache sync process will be deferred to later in the process, but it will run.

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

- ## Method Details

  - ### values

    public static CacheSyncTiming[] values()
    Returns an array containing the constants of this enum type, in the order they are declared.
    Returns:
      an array containing the constants of this enum type, in the order they are declared

  - ### valueOf

    public static CacheSyncTiming valueOf(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:
      `IllegalArgumentException` - if this enum type has no constant with the specified name
      `NullPointerException` - if the argument is null

  - ### getValue

    public String getValue()
    Specified by:
      `getValue` in interface `ValueEnum`