public class DataSource
extends java.lang.Object
 This class is not meant to be created and used, it is actually documentation of settings
 allowed in a DataSource descriptor (.ds.xml file), for use with Smart GWT Pro Edition and
 above.
 See com.smartgwt.client.docs.serverds for how to use this documentation.
 
 Each DataSource consists of a list of fields that make up a DataSource
 record, along with field types,  validation
 rules,  relationships to
 other DataSources, and other metadata. 
The abstract object description provided by a DataSource is easily mapped to a variety of backend object models and storage schemes. The following table shows analogous terminology across systems.
| Isomorphic Smart GWT | Relational Database | Enterprise Java Beans (EJB) | Entity/Relationship Modeling | OO/UML | XML Schema/WSDL | LDAP | 
| DataSource | Table | EJB class | Entity | Class | Element Schema (ComplexType) | Objectclass | 
| Record | Row | EJB instance | Entity instance | Class instance/Object | Element instance (ComplexType) | Entry | 
| Field | Column | Property | Attribute | Property/Attribute | Attribute or Element (SimpleType) | Attribute | 
 DataSources can be declared in either JavaScript or XML format, and can also be imported
 from existing metadata formats, including XML Schema. 
 Data Binding is the process by
 which Data Binding-capable UI components
 can automatically configure themselves for viewing, editing and saving data described by
 DataSources.  DataBinding is covered in the 'QuickStart Guide', Chapter 6, Data Binding.
 
 Data Integration is the process by
 which a DataSource can be connected to server systems such as SQL DataBases, Java Object
 models, WSDL web services and other data providers.  Data Integration comes in two variants:
 client-side and server-side.  Server-side
 integration uses the Smart GWT Java-based server to connect to data represented by Java
 Objects or JDBC-accessible databases.  Client-side integration connects Smart GWT DataSources to XML, JSON or other formats
 accessible via HTTP. 
 DataSources have a concept of 4 core operations ("fetch", "add", "update" and
 "remove") that can be performed on the set of objects represented by a DataSource.  Once a
 DataSource has been integrated with your data store, databinding-capable  UI components can
 leverage the 4 core DataSource operations to provide many complete user interactions without
 the need to configure how each individual component loads and saves data. 
 These
 interactions include grid views, tree views,  detail views, form-based  editing and saving, grid-based editing and saving, and custom interactions
 provided by Pattern Reuse Example custom databinding-capable components.
| Modifier and Type | Field and Description | 
|---|---|
| DataSourceField[] | addedAuditFieldsThe list of extra manually managed fields that will be added to the  fieldsof theAudit DataSource. | 
| java.lang.Boolean | allowAdvancedCriteriaBy default, all DataSources are assumed to be capable of handling   AdvancedCriteriaon fetch or filter type operations. | 
| java.lang.Boolean | allowClientRequestedSummariesIf a  DSRequestarrives from the client that requestsserver-calculated summaries, should it be allowed? | 
| boolean | auditEnables saving of a log of changes to this DataSource in a second DataSource with the same
  fields, called the "audit DataSource". | 
| java.lang.Integer | auditChangedFieldsFieldLengthFor DataSources with  auditing
 enabled, specifies the length of the field used 
  to store the names of the fields which were updated. | 
| java.lang.String | auditChangedFieldsFieldNameFor DataSources with  auditing
 enabled, specifies the field name used to store the names of the fields which were updated. | 
| java.lang.String | auditDataSourceIDFor DataSources with  auditing
 enabled, optionally specifies the ID of the audit DataSource. | 
| java.lang.String | auditDSConstructorFor DataSources with  auditing
 enabled, optionally specifies theserverConstructorfor the
 automatically generated audit DataSource. | 
| java.lang.String | auditedDataSourceIDFor audit DataSources, this required property specifies the ID of the  auditedDataSource. | 
| java.lang.String | auditRevisionFieldNameFor DataSources with  auditing
 enabled, specifies the field name used to store the revision number for the change (in a field
 of type "sequence"). | 
| java.lang.String | auditTimeStampFieldNameFor DataSources with  auditing
 enabled, specifies the field name used to store the timestamp when the operation was performed
 (in a field of type "datetime"). | 
| java.lang.String | auditTypeFieldNameFor DataSources with  auditing
 enabled, specifies the field name used to store theoperationType(in a field of type "text"). | 
| java.lang.String | auditUserFieldNameFor DataSources with  auditing
 enabled, specifies the field name used to store the user who performed the operation. | 
| java.lang.Boolean | autoConvertRelativeDatesWhether to convert relative date values to concrete date values before sending to the  server. | 
| boolean | autoCreateAuditTableSetting  autoCreateAuditTabletotrueindicates that audit DataSource 
 will automatically create SQL table whenauditingis enabled. | 
| java.lang.Boolean | autoDeriveSchemaThis property allows you to specify that your DataSource's schema (field definitions) should
  be automatically derived from some kind of metadata. | 
| boolean | autoDeriveTitlesIf set, titles are automatically derived from  field.namefor any  field that does not
 have afield.titleand is not
 markedhidden:true, by calling
 the methodgetAutoTitle(). | 
| java.lang.String | beanClassNameThis property has different meanings depending on the  serverType: | 
| java.lang.String | callbackParamApplies only to dataFormat: "json" and  dataTransport:"scriptInclude". | 
| boolean | canMultiSortWhen true, indicates that this DataSource supports multi-level sorting. | 
| java.lang.String | childrenFieldfieldName for a field in the dataSource expected to contain an explicit array of child nodes. | 
| java.lang.Boolean | clientOnlyA clientOnly DataSource simulates the behavior of a remote data store by manipulating a static
 dataset in memory as  DSRequestsare executed on it. | 
| int | clientRequestMaxRowsApplies to  SQL DataSourcesonly. | 
| boolean | compareMetadataForAuditChangeStatusOnly applicable to  binary fieldsonauditedDataSources. | 
| java.lang.String | configBeanFor DataSources of  serverType"hibernate", the name of a Spring  bean to query to obtain Hibernate Configuration for this
 particular DataSource. | 
| java.lang.Boolean | creatorOverridesIndicates that declarative security rules are waived for rows that were created by the  current
 user. | 
| CriteriaPolicy | criteriaPolicyDecides under what conditions the  ResultSetcache should be
 dropped when theResultSet.criteriachanges. | 
| java.lang.String | dataFieldName of the field that has the most pertinent numeric, date, or enum value, for use when a
  DataBoundComponentneeds to show a short summary of a
 record. | 
| DSDataFormat | dataFormatIndicates the format to be used for HTTP requests and responses when fulfilling DSRequests (eg,
 when  fetchData()is called). | 
| RPCTransport | dataTransportTransport to use for all operations on this DataSource. | 
| java.lang.String | dataURLDefault URL to contact to fulfill all DSRequests. | 
| java.lang.String | dbNameFor DataSources using the  Smart GWT SQL enginefor persistence, which database configuration to use. | 
| java.lang.String | defaultBooleanStorageStrategyFor  serverType:"sql"DataSources, sets the defaultsqlStorageStrategyto use for
 boolean fields where nosqlStorageStrategyhas been declared on the field. | 
| MultiUpdatePolicy | defaultMultiUpdatePolicyControls when primary keys are required for "update" and "remove" server operations, when
 allowMultiUpdate  has not been explicitly configured on either the  operationBinding.allowMultiUpdateor via the server-side APIDSRequest.setAllowMultiUpdate(). | 
| java.lang.String | defaultSortFieldFor DataSources of  serverType"sql" only, the name of a field to 
  include in theORDER BYclause as a means of enforcing a stable sort 
 order, forpaged fetchesonly. | 
| TextMatchStyle | defaultTextMatchStyleThe default textMatchStyle to use for  DSRequests that do not
 explicitly state  atextMatchStyle. | 
| java.lang.String | descriptionAn optional description of the DataSource's content. | 
| java.lang.String | descriptionFieldName of the field that has a long description of the record, or has the primary text data value
 for a record that represents an email message, SMS, log or similar. | 
| java.lang.Boolean | dropExtraFieldsIndicates that for server responses, for any data being interpreted as DataSource records, 
 only data that corresponds to declared fields should be retained; any extra fields should be
 discarded. | 
| int | endGapIf we are  loading
 progressively, indicates the number of  extra records Smart GWT Server will advertise as being
 available, if it detects that  there are more records to view (seelookAhead). | 
| java.lang.String | enumConstantPropertyThe name of the property this DataSource uses for constant name when translating Java
 enumerated types to and from Javascript, if the  EnumTranslateStrategyis set to "bean". | 
| java.lang.String | enumOrdinalPropertyThe name of the property this DataSource uses for ordinal number when translating Java
 enumerated types to and from Javascript, if the  EnumTranslateStrategyis set to "bean". | 
| EnumTranslateStrategy | enumTranslateStrategySets the strategy this DataSource uses to translate Java enumerated types (objects of type
 enum) to and from Javascript. | 
| DataSourceField[] | fieldsThe list of fields that compose records from this DataSource. | 
| java.lang.String | fileContentsFieldThe native field name used by this DataSource on the server to represent the
  fileContentsforFileSource
 Operations. | 
| java.lang.String | fileFormatFieldThe native field name used by this DataSource on the server to represent the
  fileFormatforFileSource Operations. | 
| java.lang.String | fileLastModifiedFieldThe native field name used by this DataSource on the server to represent
  fileLastModifiedforFileSource
 Operations. | 
| java.lang.String | fileNameFieldThe native field name used by this DataSource on the server to represent the
  fileNameforFileSource Operationsoperations. | 
| java.lang.String | fileTypeFieldThe native field name used by this DataSource on the server to represent the
  fileTypeforFileSource Operations. | 
| java.lang.String | fileVersionFieldThe native field name used by this DataSource on the server to represent
  fileVersionforFileSource Operations. | 
| java.lang.String | forceSortFor DataSources of  serverType"sql" only, indicates whether we should automatically add a sort field forpaged fetcheson  this DataSource. | 
| boolean | generateAuditDSFor an  auditedDataSource, controls
 whether the Framework will attempt to auto-generate the audit DataSource. | 
| java.util.Map | globalNamespacesNamespaces definitions to add to the root element of outbound XML messages sent to a web
  service, as a mapping from namespace prefix to namespace URI. | 
| java.lang.String | guestUserIdValue to use for the  ownerIdFieldif no one  has authenticated. | 
| java.lang.String | iconField | 
| java.lang.String | IDUnique identifier for this DataSource. | 
| java.lang.String | idClassNameFor JPA and Hibernate DataSources this property indicates, that data source has composite
 primary key and specifies fully-qualified Java class: with
  @EmbeddedIdyou have to specify class name of declared id with@IdClassyou have to specify class specified in annotation
 declaration | 
| java.lang.Boolean | ignoreTextMatchStyleCaseSensitiveFor fields on this dataSource that specify   ignoreTextMatchStyletrue, the prevailing textMatchStyle is ignored and Smart GWT matches exact values. | 
| Criteria | implicitCriteriaCriteria that are implicitly applied to all fetches made through this DataSource. | 
| java.lang.String | infoFieldName of the field that has the second most pertinent piece of textual information in the
 record, for use when a  DataBoundComponentneeds to show a
 short summary of a record. | 
| DSInheritanceMode | inheritanceModeFor dataSources of  serverType"sql" and "hibernate", specifies the inheritance  mode to use. | 
| java.lang.String | inheritsFromID of another DataSource this DataSource inherits its  fieldsfrom. | 
| java.lang.String | jsonPrefixAllows you to specify an arbitrary prefix string to apply to all json format responses  sent
 from the server to this application. | 
| java.lang.String | jsonSuffixAllows you to specify an arbitrary suffix string to apply to all json format responses  sent
 from the server to this application. | 
| java.lang.Integer | logSlowAddAllows you to specify  "add" operationSQL
 query execution  time threshold in milliseconds, which if exceeded query is identified as
 "slow" and  may be logged under specific logging category. | 
| java.lang.Integer | logSlowCustomAllows you to specify  "custom" operationSQL
 query execution  time threshold in milliseconds, which if exceeded query is identified as
 "slow" and  may be logged under specific logging category. | 
| java.lang.Integer | logSlowFetchAllows you to specify  "fetch" operationSQL
 query execution  time threshold in milliseconds, which if exceeded query is identified as
 "slow" and  may be logged under specific logging category. | 
| java.lang.Integer | logSlowRemoveAllows you to specify  "remove" operationSQL
 query execution  time threshold in milliseconds, which if exceeded query is identified as
 "slow" and  may be logged under specific logging category. | 
| java.lang.Integer | logSlowSQLAllows you to specify SQL query execution time threshold in milliseconds, which if exceeded 
 query is identified as "slow" and may be logged under specific logging category. | 
| java.lang.Integer | logSlowUpdateAllows you to specify  "update" operationSQL
 query execution  time threshold in milliseconds, which if exceeded query is identified as
 "slow" and  may be logged under specific logging category. | 
| int | lookAheadIf we are  loading
 progressively, indicates the number of  extra records Smart GWT Server will read beyond the
 end record requested by the client, in order to establish if there are more records to view. | 
| java.lang.Integer | maxFileVersionsIf  automatic file
 versioningis enabled for a FileSource DataSource, this property configures the maximum number
 of versions to retain. | 
| Criteria | mockDataCriteriaWhen  mockModeis enabled, criteria to
 use in an initial "fetch" DSRequest to retrieve sample data. | 
| java.lang.Integer | mockDataRowsWhen  mockModeis enabled, number of
 rows of data to retrieve via an initial "fetch" DSRequest, for use as sample data. | 
| boolean | noNullUpdatesWhen true, indicates that fields in this DataSource will never be positively updated to the
 null value; they may arrive at null values by being omitted, but we will  not send actual null
 values in update requests. | 
| boolean | nullBooleanValueIf  noNullUpdatesis set, the
 value to use for any boolean field that has a null value assigned on an update operation, and
 does not specify an explicitnullReplacementValue. | 
| Date | nullDateValueIf  noNullUpdatesis set, the
 value to use for any date or time field that has a null value assigned on an update operation,
 and does not specify an explicitnullReplacementValue. | 
| float | nullFloatValueIf  noNullUpdatesis set, the
 value to use for any float field that has a null value assigned on an update operation, and
 does not specify an explicitnullReplacementValue. | 
| int | nullIntegerValueIf  noNullUpdatesis set, the
 value to use for any integer field that has a null value assigned on an update operation, and
 does not specify an explicitnullReplacementValue. | 
| java.lang.String | nullStringValueIf  noNullUpdatesis set, the
 value to use for any text field that has a null value assigned on an update operation, and does
 not specify an explicitnullReplacementValue. | 
| boolean | omitNullDefaultsOnAddWhen true, and  noNullUpdatesis also true, indicates that "add"  requests on this DataSource will have null-valued fields
 removed from the request  entirely before it is sent to the server, as opposed to the default
 behavior of  replacing such null values with defaults. | 
| OperationBinding[] | operationBindingsOptional array of OperationBindings, which provide instructions to the DataSource about how
 each
  DSOperation is to be performed. | 
| java.lang.String | ownerIdFieldRequires that the currently authenticated user match the contents of
  this field, for client-initiated requests (i.e., where
   DSRequest.isClientRequest()returns true on the server). | 
| NullAccessType | ownerIdNullAccessIf  ownerIdFieldis in force,
 specifies the access that  is allowed to records with a nullownerIdField. | 
| java.lang.String | ownerIdNullRoleIf  ownerIdFieldis in force,
 specifies a role that will allow theownerIdFieldto take a null value. | 
| java.lang.String | pluralTitleUser-visible plural name for this DataSource. | 
| java.lang.Boolean | preventHTTPCachingIf set, the DataSource will ensure that it never uses a cached HTTP response, even if the
 server marks the response as cacheable. | 
| java.lang.Boolean | progressiveLoadingIf true, causes Smart GWT Server to use the "progressive loading" pattern for  fetches on this
 dataSource, as described in the Paging and total dataset length section of the  ResultSet documentation. | 
| int | progressiveLoadingThresholdIndicates the dataset size that will cause Smart GWT Server to automatically switch into  progressive loading modefor
 this DataSource. | 
| java.lang.String | projectFileKeyFor DataSources with type  , looks up the locations to use asprojectFileLocationsfrom
 the project's configuration (i.e. | 
| java.lang.String[] | projectFileLocationsFor DataSources with type  ,
  specifies locations for the project files. | 
| java.lang.Boolean | qualifyColumnNamesFor dataSources of  serverType"sql", determines whether we qualify column names with table names in any SQL we generate. | 
| java.lang.Boolean | quoteColumnNamesIf set, tells the SQL engine to quote column names in all generated DML and DDL  statements for
 this dataSource. | 
| java.lang.Boolean | quoteTableNameFor SQL DataSources, tells the framework whether to surround the associated   table namewith quotation marks
 whenever it appears in generated queries. | 
| java.lang.String | recordNameProvides a default value for  OperationBinding.recordName. | 
| XPathExpression | recordXPath | 
| java.lang.String | relatedTableAliasFor a  SQL DataSourcethat is referred byadditional foreign keys, this
 property defines the table alias name to use in generated SQL. | 
| int | requestMaxRowsApplies to  SQL DataSourcesonly. | 
| DSRequest | requestPropertiesAdditional properties to pass through to the  DSRequests made
 by this DataSource. | 
| VelocityExpression | requiresIndicates that the specified  VelocityExpressionmust evaluate
 to true for a user  to access this DataSource. | 
| java.lang.Boolean | requiresAuthenticationWhether a user must be authenticated in order to access this DataSource. | 
| java.lang.String | requiresRoleSimilar to  OperationBinding.requiresRole, but controls access to the DataSource as a whole. | 
| int | resultBatchSizeVery advanced: for servers that do not support paging, and must return large numbers of XML
 records in one HTTP response, Smart GWT breaks up the processing of the response in order to
 avoid the "script running slowly" dialog appearing for an end user. | 
| java.util.Map | resultSetClassClass for ResultSets used by this datasource. | 
| java.util.Map | resultTreeClassClass for ResultTrees used by this datasource. | 
| java.lang.String | schemaThis property only applies to the built-in SQL DataSource provided in Pro and better 
 editions of Smart GWT | 
| java.lang.String | schemaBeanFor DataSources that specify  autoDeriveSchema, this property
 indicates the name of the Spring bean, Hibernate mapping or fully-qualified Java class to use
 as parent  schema. | 
| java.lang.String | schemaNamespaceFor a DataSource derived from WSDL or XML schema, the XML namespace this schema belongs to. | 
| java.lang.String | scriptDefault scriptlet to be executed on the server for each operation. | 
| java.lang.Boolean | sendExtraFieldsAnalogous to  dropExtraFields, for data sent to the server. | 
| SequenceMode | sequenceModeFor fields of  type"sequence" in
 a dataSource ofserverType"sql", indicates theSequenceModeto use. | 
| java.lang.String | serverConstructorThis property allows you to write and use custom DataSource subclasses on the server, by 
 specifying either  the fully-qualified name of the DataSource subclass that should be
 instantiated server-side for this dataSource, or the token "spring:" followed by a
 valid Spring bean ID, if you wish to instantiate  your custom dataSource object using Spring
 dependency injection. | 
| ServerObject | serverObjectFor Direct Method Invocation (DMI) binding, declares the ServerObject to use as the default
 target for all  operationBindings. | 
| java.lang.String | serverOnlySetting a DataSource to be  serverOnly="true"ensures that it will not be visible
 to the client. | 
| DSServerType | serverTypeFor a DataSource stored in .xml format on the Smart GWT server, indicates what server-side
 connector to use to execute requests, that is, what happens if you call dsRequest.execute() in
 server code. | 
| java.lang.String | serviceNamespaceFor an XML DataSource, URN of the WebService to use to invoke operations. | 
| java.lang.Boolean | showLocalFieldsOnlyFor a DataSource that inherits  fieldsfrom another DataSource  (viainheritsFrom), indicates that only
 the fields listed in this DataSource should be shown. | 
| java.lang.Boolean | showPromptWhether RPCRequests sent by this DataSource should enable  RPCRequest.showPromptin order to block user
 interactions until the request completes. | 
| boolean | sparseUpdatesWhen true, indicates that any updates for this DataSource include only those fields  that have
 actually changed (and primaryKey fields); when false (the default), all  field values are
 included in updates, whether they have changed or not | 
| SQLPagingStrategy | sqlPagingThe paging strategy to use for this DataSource. | 
| java.lang.Boolean | sqlUsePagingHintIf explicitly set true or left null, causes the server to use a "hint" in the SQL we  generate
 for paged queries. | 
| java.lang.Boolean | strictSQLFilteringIf set to true, both client and server-side advanced filtering used by Smart GWT will follow
  SQL99 behavior for dealing with NULL values, which is often counter-intuitive to users. | 
| java.lang.String | tableCodeOnly applicable to the built-in SQL DataSource | 
| java.lang.String | tableNameFor DataSources using the  Smart GWT SQL enginefor persistence, what database table name to use. | 
| java.lang.String | tagNameTag name to use when serializing to XML. | 
| java.lang.String | titleUser-visible name for this DataSource. | 
| java.lang.String | titleFieldBest field to use for a user-visible title for an individual record from this dataSource. | 
| java.lang.Boolean | transformMultipleFieldsIf set to "false", transformation of values for  multiple:truefields, normally
 controlled byDataSourceField.multipleStorage, is instead disabled for this entire DataSource. | 
| java.lang.String | transformRawResponseScriptApplicable to  server-side
 REST DataSourcesonly | 
| java.lang.Boolean | trimMillisecondsFor this dataSource, should the millisecond portion of time and datetime values be  trimmed off
 before before being sent from client to server or vice versa. | 
| java.lang.Boolean | useAnsiJoinsFor DataSources using the  Smart GWT SQL enginefor persistence, whether to use ANSI-style joins (ie, joins implemented with JOIN directives in
 the table clause, as opposed to additional join expressions in the where clause). | 
| java.lang.Boolean | useFlatFieldsLike  DataBoundComponent.useFlatFields, but applies to all DataBound components that bind to this
 DataSource. | 
| java.lang.Boolean | useLocalValidatorsWhether to attempt validation on the client at all for this DataSource. | 
| java.lang.Boolean | useOfflineStorageWhether we store server responses for this DataSource into   browser-based offline storage, and then use those stored
 responses at a later time if we are offline (ie, the application cannot connect to the server). | 
| java.lang.Boolean | useParentFieldOrderFor a DataSource that inherits  fieldsfrom another DataSource  (viainheritsFrom), indicates that the
 parent's field order should be used instead of the order of the fields as declared in this
 DataSource. | 
| java.lang.Boolean | useSequencesFor a DataSource with  serverType:"sql", this flag indicates  whether any fields oftype"sequence" should be backed by a 
 native database sequence (if the flag is true) or an auto-increment/identity column (if it is
 false). | 
| java.lang.Boolean | useSubselectForRowCountThis property is only applicable to  SQLDataSources, and  only foroperationsthat express acustomSQLclause. | 
| java.util.Map | xmlNamespacesSets the XML namespace prefixes available for XPaths on a DataSource-wide basied. | 
| Constructor and Description | 
|---|
| DataSource() | 
public java.lang.Boolean sqlUsePagingHint
OperationBinding.sqlUsePagingHint.  Note this property is only applicable to SQL DataSources,  only when a paging strategy of "sqlLimit" is in
 force, and it only has an effect for those specific database products where we employ a native
 hint in the generated SQL in an attempt to improve performance.
 
Default value is null
OperationBinding.sqlUsePagingHintpublic int resultBatchSize
 If you have a
 relatively small number of records with a great deal of properties or subobjects on each
 record, and you have not set dropExtraFields to eliminate
 unused data, and you see the "script running slowly" dialog, you may need to set this number
 lower.
 
Default value is 150
public java.lang.String beanClassName
serverType:  For SQL DataSources
 (DataSources with serverType "sql")
 If set, results from the database will be used to
 create one instance of the indicated Java bean per database row.  Otherwise a Map is used to
 represent each row retrieved from SQL. 
 With this feature active, a DSResponse from this
 DataSource will contain a Collection of instances of the indicated beanClassName,
 available via DSResponse.getData(). This creates a couple of possibilities: 
DMI method that calls DSRequest.execute()
 to retrieve a DSResponse, you have an opportunity to call business logic methods on the beans
 representing each row affected by the DSRequest.  For example, notify a related BPEL process of
 changes to certain fields. By using beanClassName on a specific
 OperationBinding, you can: 
 Note that beanClassName affects what numeric field types will be used for 
 inbound DSRequest data. For fields with numeric types, the record data  in DSRequests will automatically be
 converted to the type of the target field, before the  request is received in a DMI.  For
 details, see DsRequestBeanTypes. 
 Note that DMI also has a built-in facility for populating a bean 
 with the inbound DSRequest.data - just
 declare the bean as a method argument. 
 For generic DataSources (DataSources with
 serverType "generic")
 Reify sets this property
 when it creates a generic  DataSource using the Javabean Wizard.  It has no built-in
 server-side effects. 
 For Hibernate DataSources (DataSources with serverType
 "hibernate")
 The name of the Java bean or POJO class that is mapped in Hibernate.  This
 will typically  be the fully-qualified class name - eg com.foo.MyClass - but it
 may be the  simple class name - just MyClass - or it may be some other value.  It
 all  depends on how your classes have been mapped in Hibernate. 
 The declared Java bean will
 affect how its properties will be mapped to built-in numeric  types, see Hibernate Integration overview for details. 
Note: If you are intending to use Hibernate as a data-access layer only, you do not need to create Hibernate mappings or Java objects: Smart GWT will generate everything it needs on the fly.
 For JPA DataSources (DataSources with serverType "jpa" or "jpa1")
 The fully
 qualified class name of the JPA annotated entity. 
NOTE for Hibernate and JPA users: When you use JPA, or use Hibernate as a full ORM system (ie, not just allowing Smart GWT Server to drive Hibernate as a data access layer), the beans returned on the server-side are live. This means that if you make any changes to them, the ORM system will persist those changes. This is true even if the beans were created as part of a fetch operation.
This causes a problem in the common case where you want to use a DMI or custom DataSource implementation to apply some post-processing to the beans fetched from the persistent store. If you change the values in the beans directly, those changes will be persisted.
 If you
 want to alter the data returned from a JPA or Hibernate persistent store as part of a fetch
 request just so you can alter what gets sent to the client, you can use the  server-side
 DSResponse's getRecords() method.  This will return your bean data in
 "record" format - ie, as a List of Maps.  You can alter these records  without affecting your
 persistent store, and then call setData() on the  DSResponse),
 passing the altered list of records.  See the server-side Javadocs for DSResponse
 for details of these two methods.
 
Default value is null
OperationBinding.beanClassNamepublic java.lang.String auditDataSourceID
auditing
 enabled, optionally specifies the ID of the audit DataSource.  If this property is not
 specified, the ID of the audit DataSource will be audit_[OriginalDSID] 
 Default value is null
public java.lang.String serverConstructor
"spring:MyDataSourceBean".  See also ServerInit for special concerns with framework initialization when
 using Spring.  It is also particularly important that you read the discussion of caching and
 thread-safety linked to below, as there are  special considerations in this area when using
 Spring."cdi:MyDataSourceBean".One reason you might wish to do this would be to override the validate() method to provide some arbitrary custom validation (such as complex database lookups, validation embedded in legacy applications, etc). It is also possible - though obviously a more substantial task - to override the execute() method in your custom DataSource. This is one way of creating a completely customized DataSource implementation.
 Note: If you use this property, you are responsible for making sure
 that it refers to a valid server-side class that extends
 com.isomorphic.datasource.BasicDataSource, or to a Spring bean of the same
 description. If your implementation relies on methods or state only present in certain
 specialized  subclasses of DataSource (for example, you want the normal behavior and features
 of a  HibernateDataSource, but with a specialized validate() method), then you should extend
 the  subclass rather than the base class. 
 NOTE: Please take note of the points made in 
 this discussion of caching and
 thread-safety issues in server-side DataSources.
 
Default value is null
public DSDataFormat dataFormat
fetchData() is called).
 Default value is "iscServer"
public java.lang.String jsonSuffix
The inclusion of such a suffix ensures your code is not directly executable outside of your application, as a preventative measure against javascript hijacking.
Only applies to responses formatted as json objects. Does not apply to responses returned via scriptInclude type transport.
Default value is null
public SequenceMode sequenceMode
type "sequence" in
 a dataSource of 
 serverType "sql", indicates the
 
 SequenceMode to use.  This property has no effect for fields
 or dataSources of 
  other types.
  
  You can set a default sequenceMode for all DataSources of a given database type by setting
  property "sql.{database_type}.default.sequence.mode" in server.properties.  
  You set a global default sequenceMode that applies to all database types by setting property
  "sql.default.sequence.mode".  For example:
    sql.mysql.default.sequence.mode: jdbcDriver
  
  
Default value is "native"
public SQLPagingStrategy sqlPaging
server.properties setting sql.defaultPaging, is used.    This setting can be
 overridden with the OperationBinding.sqlPaging property. 
 NOTE: Operations that involve a customSQL  clause ignore this property,
 because customSQL operations usually need to be treated as special cases.  For these
 operations, the paging strategy comes from the  server.properties setting
 sql.defaultCustomSQLPaging or  sql.defaultCustomSQLProgressivePaging,
 depending on whether or not  progressiveLoading is in
 force.  Note that these can always be overridden by a sqlPaging setting on the
 OperationBinding.
 
Default value is null
OperationBinding.sqlPagingpublic java.lang.String script
OperationBinding.script is
 specified, it will be executed for the operation binding in question instead of running this
 scriptlet.
  
 Scriptlets are used similarly to DMIs configured via serverObject or
 OperationBinding.serverObject -
  they can add business logic by modifying the DSRequest before it's executed, modifying the
  default DSResponse, or taking other, unrelated actions.  
  
For example:
     <DataSource>
        <script language="groovy">
           ... Groovy code ...
        </script>
       ... other DataSource properties
     </DataSource>
  
  
  Scriptlets can be written in any language supported by the "JSR 223" standard, including Java
 itself.  See the DMI Script Overview for rules on
 how to return data,
  add additional imports, and other settings.
  
The following variables are available for DMI scriptlets:
automatic
 transactions are enabled, this
  SQLConnection is in the context of the current transaction.
  Scriptlets also have access to a set of contextual variables related to the Servlets API, as follows:
HttpSession
  prevents your DataSource from being used in a command-line process.
  
  Note that if a dataSource configuration has both a <script> block and
 a specified serverObject for some operation, the
  script block will be executed, and the serverObject ignored.
 
Default value is null
public java.lang.String fileNameField
fileName for FileSource Operations
 operations. Any extensions to the fileName to indicate type or format (e.g. ".ds.xml") are
 stored in the fileTypeField
 and fileFormatField, if
 specified for this DataSource. If not specified for a DataSource, the fileNameField will be inferred on the server as follows:
Default value is null
FileSource overview and related methodspublic java.lang.String auditUserFieldName
auditing
 enabled, specifies the field name used to store the user who performed the operation.  If
 empty string is specified as the field name, the audit DataSource will not store this field.
 Default value is "audit_modifier"
public OperationBinding[] operationBindings
  When using the Smart GWT Server, OperationBindings are specified in your DataSource
  descriptor (.ds.xml file) and control server-side behavior such as what Java object to route
 DSRequest to (OperationBinding.serverObject) or customizations to SQL, JQL and HQL queries
 (OperationBinding.customSQL,
 OperationBinding.customJQL and
 OperationBinding.customHQL).
 See the @see Java Integration samples.
  
  For DataSources bound to WSDL-described web services using
 serviceNamespace,
 OperationBindings are used to bind each DataSource
  operationType to an
 operation of a WSDL-described 
 web service, so that a DataSource can both fetch
 and save data to a web
  service.
  
For example, this code accomplishes part of the binding to the SalesForce partner web services
       DataSource dataSource = new DataSource();
       dataSource.setServiceNamespace("urn:partner.soap.sforce.com");
       OperationBinding fetch = new OperationBinding();
       fetch.setOperationType(DSOperationType.FETCH);
       fetch.setWsOperation("query");
       fetch.setRecordName("sObject");
       OperationBinding add = new OperationBinding();
       add.setOperationType(DSOperationType.ADD);
       add.setWsOperation("create");
       add.setRecordName("SaveResult");
       OperationBinding update = new OperationBinding();
       update.setOperationType(DSOperationType.UPDATE);
       update.setWsOperation("update");
       update.setRecordName("SaveResult");
       OperationBinding remove = new OperationBinding();
       remove.setOperationType(DSOperationType.REMOVE);
       remove.setWsOperation("delete");
       remove.setRecordName("DeleteResult");
       dataSource.setOperationBindings(fetch, add, update, remove);
  
  
  NOTE: additional code is required to handle authentication and other details, see the
  complete code in smartclientSDK/examples/databinding/SalesForce.
  
  For DataSources that contact non-WSDL-described XML or JSON services, OperationBindings can
  be used to separately configure the URL, HTTP method, input and output processing for each
  operationType.  This makes it possible to fetch JSON data from one URL for the "fetch"
  operationType and save to a web service for the "update" operationType, while appearing as a
 single integrated DataSource to a DataBoundComponent such
 as an
  editable ListGrid.
  
If no operationBinding is defined for a given DataSource operation, all of the properties which are valid on the operationBinding are checked for on the DataSource itself.
This also means that for a read-only DataSource, that is, a DataSource only capable of fetch operations, operationBindings need not be specified, and instead all operationBinding properties can be set on the DataSource itself. In the RSS Feed sample, you can see an example of using OperationBinding properties directly on the DataSource in order to read an RSS feed.
Default value is null
OperationBindingpublic java.lang.Integer logSlowRemove
"remove" operation SQL
 query execution  time threshold in milliseconds, which if exceeded query is identified as
 "slow" and  may be logged under specific logging category.  See logSlowSQL for more details.
 
Default value is null
public java.lang.String fileTypeField
fileType for FileSource Operations. 
 If the fileTypeField is not configured, then a field named "fileType" will be used, if it exists. Otherwise, the DataSource will not track fileTypes -- this may be acceptable if, for instance, you use a separate DataSource for each fileType.
The fileType is specified according to the extension that would have been used in the filesystem -- for instance, the fileType for employees.ds.xml would be "ds".
Default value is null
FileSource overview and related methodspublic java.lang.Boolean useFlatFields
DataBoundComponent.useFlatFields, but applies to all DataBound components that bind to this
 DataSource.
 Default value is null
public java.lang.String infoField
DataBoundComponent needs to show a
 short summary of a record. For example, for a DataSource of employees, a "job title" field would probably be the second most pertinent text field aside from the employee's "full name".
 Unlike titleField,
 infoField is not automatically determined in the absence of an explicit setting.
 
Default value is null
public java.util.Map xmlNamespaces
OperationBinding.xmlNamespaces for details.
 Default value is See below
public VelocityExpression requires
VelocityExpression must evaluate
 to true for a user  to access this DataSource.  See also OperationBinding.requires.
 
Default value is null
public java.lang.String ID
Default value is null
public java.lang.Integer maxFileVersions
automatic file
 versioning is enabled for a FileSource DataSource, this property configures the maximum number
 of versions to retain.
 Default value is 20
public java.lang.String tagName
dataSource.ID will
 be used.
 Default value is null
public boolean generateAuditDS
audited DataSource, controls
 whether the Framework will attempt to auto-generate the audit DataSource.  Note that this
 property is independent of auditDataSourceID so that, by
 default, even when the audit DataSource is given a non-default ID, the Framework will still
 attempt to auto-generate it.
 Default value is true
public java.lang.Boolean allowClientRequestedSummaries
DSRequest arrives from the client that requests server-calculated summaries, should it be allowed?
  Note this setting only affects dsRequests that come from the browser
 (or another client).  This setting has no effect on server summaries declared in .ds.xml files
 or summaries configured in DSRequests created programmatically on the server side, which are
 always allowed. 
 Default value of null means this DataSource will use the system-wide
 default, which is set via datasources.allowClientRequestedSummaries in server.properties, and defaults to allowing
 client-requested summaries. 
If client-requested summarization is allowed, but the server-side <operationBinding> provides specific summarization settings, the client-requested summarization is ignored.
Default value is null
public java.lang.Boolean useLocalValidators
Disabling client-side validation entirely is a good way to test server-side validation.
Default value is null
Validation overview and related methodspublic EnumTranslateStrategy enumTranslateStrategy
Default value is null
public java.lang.Boolean clientOnly
DSRequests are executed on it. 
 Any changes are lost when the user reloads the page or navigates away. A clientOnly DataSource will return responses asynchronously, just as a DataSource accessing remote data does. This allows a clientOnly DataSource to be used as a temporary placeholder while a real DataSource is being implemented - if a clientOnly DataSource is replaced by a DataSource that accesses a remote data store, UI code for components that used the clientOnly DataSource will not need be changed.
 A clientOnly DataSource can also be used as a shared cache of
 modifiable data across multiple UI components when immediate saving is not desirable.  In this
 case, several components may interact with a clientOnly DataSource and get the benefit of
 ResultSet behaviors such as automatic cache sync and
 in-browser data filtering and sorting.  When it's finally time to save, cacheData can be inspected for changes and
 data can be saved to the original DataSource via addData(), updateData() and removeData(), possibly in a transactional queue.  Note that getClientOnlyDataSource() lets you
 easily obtain a clientOnly DataSource representing a subset of the data available
 from a normal DataSource.   
 See also cacheAllData - a cacheAllData
 behaves like a write-through cache, performing fetch and filter operations locally while still
 performing remote save operations immediately. 
 ClientOnly DataSources can be populated
 programmatically via cacheData - see
 this discussion for other ways to
 populate a client-only DataSource with data.
 
Default value is false
public java.lang.Boolean ignoreTextMatchStyleCaseSensitive
ignoreTextMatchStyle
 true, the prevailing textMatchStyle is ignored and Smart GWT matches exact values.  This
 property dictates whether that match is case-sensitive like the "exactCase" textMatchStyle, or 
 case-insensitive like the "exact" textMatchStyle (the default).  Please see the  TextMatchStyle documentation for a discussion of the
 nuances of case-sensitive matching.
 Default value is false
public CriteriaPolicy criteriaPolicy
ResultSet cache should be
 dropped when the ResultSet.criteria
 changes.
 Default value is "dropOnShortening"
public java.lang.Integer logSlowAdd
"add" operation SQL
 query execution  time threshold in milliseconds, which if exceeded query is identified as
 "slow" and  may be logged under specific logging category.  See logSlowSQL for more details.
 
Default value is null
public java.lang.String callbackParam
dataTransport:"scriptInclude". 
 Specifies the name of the query parameter that tells your JSON service what function to call as
 part of the response.
 Default value is "callback"
public java.lang.String auditTimeStampFieldName
auditing
 enabled, specifies the field name used to store the timestamp when the operation was performed
 (in a field of type "datetime").  If empty string is specified as the field name, the audit
 DataSource will not store this field.
 Default value is "audit_changeTime"
public Criteria mockDataCriteria
mockMode is enabled, criteria to
 use in an initial "fetch" DSRequest to retrieve sample data.
 Default value is null
public int progressiveLoadingThreshold
progressive loading mode for
 this DataSource. To prevent automatic switching to progressive loading, set this property to
 -1. This may also be prevented on a per-request basis by setting DSRequest.progressiveLoading to
 false.
 Default value is 200000
public java.lang.Boolean showLocalFieldsOnly
fields from another DataSource  (via inheritsFrom), indicates that only
 the fields listed in this DataSource should be shown.  All other inherited parent fields will
 be marked "hidden:true".
 Default value is null
public java.lang.String serviceNamespace
 Having
 loaded a WebService using XMLTools.loadWSDL(), setting serviceNamespace combined with specifying  operationBindings that set OperationBinding.wsOperation will
 cause a DataSource to invoke web service operations to fulfill DataSource requests (DSRequests). 
 Setting serviceNamespace also
 defaults dataURL to the service's
 location, dataFormat to "xml"
 and dataProtocol to
 "soap".
 
Default value is null
public java.lang.String fileVersionField
fileVersion for FileSource Operations.
  Automatic file versioning is configured by the presence of this property: if you want
 automatic versioning for a FileSource DataSource, it is sufficient to simply define a 
 fileVersionField.  When automatic versioning is on:
saveFile() will save a new version of the file,
 retaining previous  versions up to the maximum configured by maxFileVersions; when that
 maximum is reached, the oldest version is overwrittengetFile() API always returns the most recent
 versionlistFiles() API only
 includes the most recent version of any filelistFileVersions() and getFileVersion() APIs.  Note that retrieving a previous version of a file and then calling
 saveFile() goes through the normal process of saving a new version
 The fileVersion field is expected to be of type "datetime", and automatic 
 versioning will not work otherwise.  Note, to minimize the possibility of version  timestamp
 collisions, we recommend that fileVersion fields specify  storeMilliseconds: true.
 
If the fileVersionField is not configured, no automatic file versioning will be done.
Default value is null
maxFileVersions, 
DataSource.listFileVersions(com.smartgwt.client.data.FileSpec, com.smartgwt.client.data.DSCallback), 
DataSource.getFileVersion(com.smartgwt.client.data.FileSpec, java.util.Date, com.smartgwt.client.callbacks.GetFileVersionCallback), 
DataSource.removeFileVersion(com.smartgwt.client.data.FileSpec, java.util.Date), 
FileSource overview and related methodspublic boolean noNullUpdates
 Setting this value causes null-assigned fields to be replaced with the field's nullReplacementValue,
 if one is declared. If no nullReplacementValue is declared for the field, the null
 assignment is replaced with the DataSource's nullStringValue,  nullIntegerValue, nullFloatValue  or nullDateValue, depending on the
 field type. 
 For "add" operations, setting omitNullDefaultsOnAdd
 causes null-valued fields to be removed from the request entirely, rather than replaced with
 default values as described above.
 
Default value is false
public java.lang.Boolean transformMultipleFields
multiple:true fields, normally
 controlled by DataSourceField.multipleStorage, is instead disabled for this entire DataSource.
 Default value is null
public java.lang.String enumConstantProperty
EnumTranslateStrategy is set to "bean".  Defaults to "_constant" if
 not set. This property is only applicable if you are using the Smart GWT server
Default value is null
public java.lang.String transformRawResponseScript
server-side
 REST DataSources only  A scriptlet to be executed on the server after data has been
 fetched from the REST service, but before it is processed through templating.   The intention is that
 this scriptlet transforms the response data in some way, before that transformed data is passed
 through templating and further downstream transformation steps  such as record transformation.  If your
 use case  does not involve templating, there is no difference between putting your
 transformation  logic in this script, or putting it in a transformResponseScript -
 they are merely pre-templating and post-templating transformation opportunities, so if no
 templating is involved, they are conceptually the same thing.  Accordingly, exactly the same 
 variables are available to the transformRawResponseScript as to the  transformResponseScript - see
 that property's documentation for details. 
 Note, if you prefer a Java solution rather than
 placing scripts in your .ds.xml  files, you can instead extend the Java
 RESTDataSource class and override its  transformRawResponse() method.
 If you both override the Java method and  provide a transformRawResponseScript,
 the Java method runs first and any  transformations it makes will be visible to the script. 
 See  serverConstructor
 for details of how to use a custom  class to implement a DataSource server-side.
 
Default value is null
script, 
com.smartgwt.client.data.DataSource#getTransformResponseScript, 
OperationBinding.transformRawResponseScript, 
ServerScript overview and related methodspublic java.lang.String recordName
OperationBinding.recordName.
 Default value is null
public int clientRequestMaxRows
SQL DataSources only.
  
  If this attribute is set to a non-negative value, it acts as a hard safety limit for 
 client-initiated DSRequests for "all rows".  If the server
 encounters more rows 
  in a response than this safety limit, it will abort immediately with an Exception.
  
This attribute is not meant to be a regular application facility. As mentioned above, it is a safety mechanism, intended primarily to prevent bugs in development from causing long delays or server Out Of Memory crashes by unintentionally issuing requests that fetch huge numbers of rows (eg, by failing to specify filter criteria).
Note the following:
endRow, or specifies
 endRow:-1.
  If you specify a non-negative endRow, it will be honored even if that 
  means we need to return more than clientRequestMaxRows recordsProgressiveLoading to stream the data progressivelyrequestMaxRows
 instead.  If both properties are specified, 
  clientRequestMaxRows wins for client-initiated requests, so it is possible
  to configure different limits for client- and server-initiated requests
  To set a default clientRequestMaxRows that will apply to all dataSources
  that do not specify the attribute, add the following to your server.properties
  file:
      # Fail with an error if we try to fetch more than 10000 rows in a client request
      sql.clientRequestMaxRows: 10000
  
 Default value is -1
clientRequestMaxRows, 
progressiveLoadingpublic RPCTransport dataTransport
defaultTransport.  This would typically
 only be set to enable "scriptInclude" transport for contacting JSON web services hosted on servers
 other than the origin server.  When using the "scriptInclude" transport, be sure to set
 callbackParam or OperationBinding.callbackParam to match the name of the query parameter name expected by your
 JSON service provider.
 
Default value is RPCManager.defaultTransport
public java.lang.Boolean dropExtraFields
 For JSON data,
 this means extra properties in selected objects are dropped. 
 By default, for DMI
 DSResponses, DSResponse.data is filtered on the server to just the set of fields defined on the
 DataSource (see the overview in DMI). 
This type of filtering can also be enabled for non-DMI DSResponses. By default it is enabled for Hibernate and JPA datasources to avoid unintentional lazy loading too much of a data model. For the rest of datasources this is disabled by default.
 Explicitly setting this property to
 false disables (or to true enables) this filtering for this
 DataSource only. This setting overrides the configuration in server.properties. This setting can be overridden
 by ServerObject.dropExtraFields.
 
Default value is null
public java.lang.String dbName
Smart GWT SQL engine
 for persistence, which database configuration to use.  Database configurations can be created
 using the Admin Console.  If unset, the default
 database configuration is used (which is also settable using the "Databases" tab).
 Default value is null
public java.lang.Boolean quoteTableName
table name with quotation marks
 whenever it appears in generated queries.  This is only required if you have to connect to a
 table with a name that is in breach of your database product's naming conventions.  For
 example, some  products (eg, Oracle) internally convert all unquoted references to upper case,
 so if you create a table called myTest, the database actually calls it 
 MYTEST unless you quoted the name in the create command, like this: 
   CREATE TABLE "myTest" 
If you do quote the name like this, or if you have to connect to a legacy table that has been named in this way, then you must set this property to tell the SQL engine that it must quote any references to this table name (this requirement depends on the database in use - as noted below, some are not affected by this problem). If you do not, you will see exceptions along the lines of "Table or view 'myTest' does not exist".
Note, other database products (eg, Postgres) convert unquoted names to lower case, which leads to the same issues. Still others (eg, SQL Server) are not case sensitive and are not affected by this issue.
Generally, we recommend that you avoid using this property unless you have a specific reason to do so. It is preferable to avoid the issue altogether by simply not quoting table names at creation time, if you are able to do so.
Default value is null
public java.lang.String fileLastModifiedField
fileLastModified for FileSource
 Operations. If the fileLastModifiedField is not configured, then a field named "fileLastModified" will be used, if it exists. Otherwise, the server will look for a field with a "modifierTimestamp" type. If that is not found, the DataSource will not keep track of the last modified date.
Default value is null
FileSource overview and related methodspublic java.lang.String descriptionField
For example, for a DataSource representing employees, a field containing the employee's "bio" might be a good choice, or for an email message, the message body.
If descriptionField is unset, it defaults to any field named "description" or "desc" in the record, or the first long text field (greater than 255 characters) in the record, or null if no such field exists.
Default value is null
public ServerObject serverObject
operationBindings.  Specifying this attribute in an XML DataSource stored on the server
 enables DMI for this DataSource.  Note that if a dataSource configuration has both a
 <script> block and a
 specified serverObject for some operation, the script block will be executed, and
 the serverObject ignored.
 
Default value is null
public java.lang.Integer logSlowCustom
"custom" operation SQL
 query execution  time threshold in milliseconds, which if exceeded query is identified as
 "slow" and  may be logged under specific logging category.  See logSlowSQL for more details.
 
Default value is null
public boolean autoDeriveTitles
field.name for any  field that does not
 have a field.title and is not
 marked hidden:true, by calling
 the method getAutoTitle().
 Default value is true
public boolean sparseUpdates
Default value is false
public java.lang.Boolean strictSQLFiltering
     field == "someValue"  (normally false)
     field != "someValue"  (normally true)
     not (field == "someValue")   (normally true)
     not (field != "someValue")   (normally false)
  
  This property can be overridden per-query by specifying strictSQLFiltering
  directly as a property on the AdvancedCriteria.
  NOTE: On the server side, this property is only applicable if you are using the SQL DataSource; the other built-in types (Hibernate and JPA/JPA2) do not offer this mode.
Default value is false
public java.lang.Boolean progressiveLoading
ResultSet documentation.  Essentially, this means that we
 avoid issuing a row count query and instead advertise total rows as being slightly  more than
 the number of rows we have already read (see endGap).  This  allows users to load more
 of a dataset by scrolling past the end of the currently-loaded rows, but it prevents them from
 scrolling directly to the end of the dataset.  Generally, progressive loading is appropriate
 when you have to deal with very large  datasets. Note that by default, a dataSource will switch
 into progressive loading mode  automatically when it detects that it is dealing with a dataset
 beyond a certain size -  see progressiveLoadingThreshold. 
 This setting can be overridden for individual fetch
 operations with the  OperationBinding.progressiveLoading property, and also at the level of the individual DSRequest.  You can also specify 
 progressiveLoading on  DataBoundComponents and
 certain types of  FormItem - SelectItem and 
 ComboBoxItem. 
 Currently, this property only applies to users of the built-in
 SQLDataSource, but you  could use it in custom DataSource implementations to trigger the server
 behavior  described in the ResultSet documentation linked to above.
 
Default value is null
public java.lang.String configBean
serverType
 "hibernate", the name of a Spring  bean to query to obtain Hibernate Configuration for this
 particular DataSource.  Note that this is intended for DataSource-specific configuration
 overrides for unusual  circumstances, such as a DataSource whose physical data store is a
 completely  different database to that used by other DataSources.  See the  Integration with Hibernate article for more 
 information
 Default value is null
public java.lang.String schemaBean
autoDeriveSchema, this property
 indicates the name of the Spring bean, Hibernate mapping or fully-qualified Java class to use
 as parent  schema.
 Default value is null
autoDeriveSchemapublic java.lang.String auditDSConstructor
auditing
 enabled, optionally specifies the serverConstructor for the
 automatically generated audit DataSource.  The default is to use the same
 serverConstructor as the DataSource where audit="true" was declared.
  This property is primarily intended to allow the use of SQLDataSource (serverType:"sql") as an audit
 DataSource for a DataSource that might be of another type.  For example, you might have a
 DataSource that implements all CRUD operations via Java logic in DMI declaration methods, and so doesn't provide generic
 storage; by using SQLDataSource as the type of your audit DataSource, you don't need to
 implement your own scheme for storing and querying audit data, and the necessary audit tables
 will be automatically generated in the database. 
Similarly, even if you do use a reusable DataSource type such as the built-in JPADataSource, using SQLDataSource for audit DataSources means there's no need to write a JPA bean just to achieve storage of an audit trail.
 To
 simplify this intended usage, the string "sql" is allowed for auditDSConstructor
 as a means of specifying that the built-in SQLDataSource class should be used.  For any other
 type, use the fully qualified Java classname, as is normal for serverConstructor.
 
Default value is null
public java.lang.String enumOrdinalProperty
EnumTranslateStrategy is set to "bean".  Defaults to "_ordinal" if
 not set. This property is only applicable if you are using the Smart GWT server
Default value is null
public java.lang.Boolean useAnsiJoins
Smart GWT SQL engine
 for persistence, whether to use ANSI-style joins (ie, joins implemented with JOIN directives in
 the table clause, as opposed to additional join expressions in the where clause). The default
 value of null has the same meaning as setting this flag to false.  Note, outer joins (see
 joinType) only work with
 certain database products if you choose not to use ANSI joins.  Other than that, the join 
 strategies are equivalent. 
 If you wish to switch on ANSI-style joins for every DataSource,
 without the need to  manually set this property on all of them, set server.properties flag 
 sql.useAnsiJoins to true.
 
Default value is null
com.smartgwt.client.data.OperationBinding#getIncludeAnsiJoinsInTableClause, 
ServerDataIntegration overview and related methodspublic java.lang.Boolean showPrompt
RPCRequest.showPrompt in order to block user
 interactions until the request completes.   DataSource requests default to blocking UI interaction because, very often, if the user continues to interact with an application that is waiting for a server response, some kind of invalid or ambiguous situation can arise.
Examples include pressing a "Save" button a second time before the first save completes, making further edits while edits are still being saved, or trying to initiate editing on a grid that hasn't loaded data.
Defaulting to blocking the UI prevents these bad interactions, or alternatively, avoids the developer having to write repetitive code to block invalid interactions on every screen.
 If an operation should ever be non-blocking, methods that
 initiate DataSource requests (such as fetchData()) will generally have a requestProperties argument allowing
 showPrompt to be set to false for a specific request.
 
Default value is true
public TextMatchStyle defaultTextMatchStyle
DSRequests that do not
 explicitly state  a textMatchStyle.    Note, however, that DSRequests  issued by ListGrids and other components will  generally have a setting for
 textMatchStyle on the component itself (see ListGrid.autoFetchTextMatchStyle, for example).
 Default value is "exact"
public java.lang.Integer mockDataRows
mockMode is enabled, number of
 rows of data to retrieve via an initial "fetch" DSRequest, for use as sample data.  Set to null
 to retrieve all available rows.
 Default value is 75
public java.lang.Boolean autoConvertRelativeDates
 If the server would
 receive relative date values from the client, by default they would be unchanged in DMI and
 automatically converted during the request execution. This may be changed via
 server.properties setting datasources.autoConvertRelativeDates which
 can be set to the following values: 
postDMI - the default value
 described above preDMI - relative date values will be converted to absolute
 date values right away, so they will be already converted in DMI disabled -
 relative date values will not be automatically converted, so it must be done completely
 manually or by calling the DSRequest.convertRelativeDates() server-side API. DataSource.convertRelativeDates(Criterion) server-side API.
 Default value is true
public java.lang.String title
For example, for the supplyItem DataSource, "Supply Item".
 If is unset, getAutoTitle() method will be used with
 dataSource.ID. value in order to derive a default value for the title. 
For example "employee" ID will be derived to "Employee", "team_member" ID will be derived to "Team Member".
Default value is dataSource.ID
public java.util.Map globalNamespaces
The default value is:
    globalNamespaces : {
       xsi: "http://www.w3.org/2001/XMLSchema-instance",
       xsd: "http://www.w3.org/2001/XMLSchema"
    },
  
  This default value allows the use of the xsi:type and xsi:nil attributes without further
  declarations.
  Note that some web services will only accept specific revisions of the XML Schema URI. If xsi-namespaced attributes seem to be ignored by an older webservice, try the URI "http://www.w3.org/1999/XMLSchema-instance" instead.
Default value is ...
public java.lang.Boolean sendExtraFields
dropExtraFields, for data sent to the server.  Setting this attribute to false ensures that
 for any records in the data object, only fields that correspond to declared dataSource fields
 will be present on the dsRequest data object passed to transformRequest() and ultimately sent to
 the server.
 Default value is true
public Criteria implicitCriteria
For example, a DataSource might *always* implicitly limit its fetch results to records owned by the current user's department. Components and ResultSets requesting data from the DataSource can then apply further implicitCriteria of their own, separately from their regular, user-editable criteria.
 For instance, a grid bound to this
 dataSource might be further limited to  implicitly show only the subset of records created by
 the current user.  See  DataBoundComponent.implicitCriteria and ResultSet.implicitCriteria for  more on
 these localized options. 
 Note that, while implicitCriteria can be declared in
 a server DataSource  file using Component XML, it
 is an entirely client-side  feature, added by client-side components.  So it does not affect
 server-side requests,  and will not be added to client-side requests that don't come from a
 Smart GWT UI  (eg RestHandler).
 
Default value is null
public java.lang.String pluralTitle
For example, for the supplyItem DataSource, "Supply Items".
 Defaults to dataSource.title + "s".
 
Default value is dataSource.ID
public java.lang.String tableName
Smart GWT SQL engine
 for persistence, what database table name to use.  The default is to use the DataSource ID as
 the table name.
 Default value is null
public XPathExpression recordXPath
OperationBinding.recordXPath.  recordXPath can be specified directly on the
 DataSource for a simple read-only DataSource only capable of "fetch" operations, or on
 clientOnly DataSources using $link{groupDef:testData}.
 Default value is null
public java.lang.Boolean useSubselectForRowCount
SQL DataSources, and  only for operations that express a  customSQL clause.  In these
 circumstances, we  generally switch off paging because we are unable to generate a "row count"
 query that tells the framework the size of the complete, unpaged resultset.  The
 useSubselectForRowCount flag causes the framework to derive a rowcount query by
 simply wrapping the entire customSQL clause in a subselect, like so:
     SELECT COUNT(*) FROM ({customSQL clause here})
However, this is not guaranteed to give good results. Because the customSQL clause can contain anything that you can write in SQL, running it inside a subselect in order to count the rows might not work, might have unintended side-effects (if, for example, it is a stored procedure call that performs updates as part of its function), or it might just be a bad idea - for example, if the customSQL query is slow-running, you'll make it twice as slow with this flag, simply because you'll be running it twice. We recommend using this flag with care.
 NOTE: This
 setting can be overridden per-operation - see  OperationBinding.useSubselectForRowCount.  You can also set a global default for this setting,
 so you don't have to specify it in every dataSource - define 
 useSubselectForRowCount as true in your  server.properties file.
 
Default value is null
public java.lang.String fileContentsField
fileContents for FileSource
 Operations. If the fileContentsField is not configured, then a field named "fileContents"
 or "contents" will be used, if it exists.  If not found, the longest
 text field which is not the fileNameField, fileTypeField or fileFormatField will be used. 
Note that the only method which will actually return the
 fileContents is getFile() -- the other
 FileSource methods omit the fileContents for the
 sake of efficiency.
 
Default value is null
FileSource overview and related methodspublic DSServerType serverType
Default value is "generic"
public int requestMaxRows
SQL DataSources only.
  
 The same as clientRequestMaxRows, but applies 
  to all requests, not just client-initiated ones.  See the documentation for 
  clientRequestMaxRows for details.  To reiterate the warning given for 
  that property, this is a safety limit that results in an Exception being thrown: it
  is not intended to be used as a regular application facility
  
  To set a default requestMaxRows that will apply to all dataSources that do
  not specify the attribute, add the following to your server.properties
  file:
      # Fail with an error if we try to fetch more than 50000 rows in any request
      sql.clientRequestMaxRows: 50000
  
 Default value is -1
clientRequestMaxRows, 
progressiveLoadingpublic java.lang.Boolean preventHTTPCaching
 Note that this does not disable caching at higher
 levels in the framework, for example, the caching performed by ResultSet.
 
Default value is true
public boolean canMultiSort
Default value is true
public java.lang.Boolean requiresAuthentication
operationBindings within the
 DataSource may still override this setting by explicitly setting OperationBinding.requiresAuthentication.  Whether the user is authenticated is determined
 by calling httpServletRequest.getRemoteUser(), hence works with both simple J2EE
 security (realms and form-based authentication) and JAAS (Java Authentication & Authorization
 Service). 
 If you wish to use an authentication scheme that does not make use of the servlet
 API's  standards, Smart GWT Server also implements the setAuthenticated method on
 RPCManager.  You can use this API to tell Smart GWT that all the  requests in the
 queue currently being processed are associated with an authenticated user; in this case, Smart
 GWT will not attempt to authenticate the user via 
 httpServletRequest.getRemoteUser() 
 You can set the default value for this
 property via setting "authentication.defaultRequired" in server.properties.  This allows you to, for
 example, cause all DataSources to require authentication for all operations by default. 
 Note that setting this property does not automatically cause an authentication mechanism to
 appear - you still need to separately configure an authentication system.  Likewise, setting
 requiresAuthentication="false" does not automatically allow users to bypass your authentication
 mechanism - you need to set up a URL that will accept DSRequests and process them similar to
 the default "IDACall" servlet, and which is not protected by the authentication system.  See
 Deploying Smart GWT for details on the IDACall
 servlet.
 
Default value is null
public java.lang.Integer logSlowFetch
"fetch" operation SQL
 query execution  time threshold in milliseconds, which if exceeded query is identified as
 "slow" and  may be logged under specific logging category.  See logSlowSQL for more details.
 
Default value is null
public java.lang.String titleField
For example, for a DataSource of employees, a "full name" field would probably most clearly label an employee record.
If not explicitly set, the titleField is determined by looking for fields named "name", "dataSourceIdName", "title", "dataSourceIdTitle", "label", "dataSourceIdLabel", "id" and "dataSourceIdId". For example, for a DataSource with ID "customer", a field called customerName would be found if there were no "name" field. Search is case insensitive, and an underscore is allowed after dataSourceId (so that, for example, "CUSTOMER_NAME" would also be found and preferred).
For purposes of this search, any trailing numerals in the DataSource ID are discarded, so a DataSource with ID "office2" will search for title fields as if the ID were just "office".
If no field is found that matches any of the names above, then the first field is designated as the titleField.
Default value is see below
public java.lang.Boolean creatorOverrides
In order for this to work, we require two things:
this pageDefault value is null
public java.util.Map resultSetClass
ResultSet. This can be set to a custom subclass of ResultSet that, for example, hangs onto to extra information necessary for integration with web services.
Default value is null
public java.lang.Integer logSlowSQL
 This
 setting applies to all SQL queries, unless more specific thresholds are set using  logSlowFetch, logSlowAdd,  logSlowUpdate, logSlowRemove,  logSlowCustom or even more specific
 affecting just the  operationBinding it is configured at:  operationBinding.logSlowSQL. 
 If
 none of the thresholds above are set, global sql.log.queriesSlowerThan  server.properties SQL setting will be used. 
 For the
 details on how to setup the logging part see the  Special logging category: com.isomorphic.SLOW_SQL
 
Default value is null
public NullAccessType ownerIdNullAccess
ownerIdField is in force,
 specifies the access that  is allowed to records with a null ownerIdField.  This
 property has no  effect if ownerIdField is not specified.  This property can be
 used in conjunction with ownerIdNullRole to  create the concept of shared, or public, records.  For example, if you set
 ownerIdNullRole to "administrator", any users with the "administrator"  role will
 be allowed to write records with a null ownerIdField.  If you  also set
 ownerIdNullAccess to "view", all those records with a null owner will be viewable
 by all, in addition to their own records.  We use this functionality  with the Saved Searches feature, to enable precisely this: 
 users can save their own searches, which are private to them, but administrators can  also save
 searches with a null ownerIdField, which become standard, shared searches that
 appear to all users, in addition to their own private searches.
 
Default value is null
ownerIdField, 
ownerIdNullRolepublic java.lang.String iconField
type:"image" as the field to
 use when rendering a record as an image, for example, in a TileGrid. For example, for a DataSource of employees, a "photo" field of type "image" should be designated as the iconField.
If not explicitly set, iconField looks for fields named "picture", "thumbnail", "icon", "image" and "img", in that order, and will use any of these fields as the iconField if it exists and has type "image".
 To avoid any field being used as the iconField, set iconField to null.
 
Default value is see below
public java.lang.String forceSort
serverType
 "sql" only, indicates whether we should automatically add a sort field for paged fetches on  this DataSource.  If left
 unset, this property defaults to the one of the global values  described in the defaultSortField documentation. 
 Also note, this property can be overridden  per-operationBinding.  Note,
 the ability to set this property per-DataSource is only provided to allow for complete
 configurability in unusual cases.  See the defaultSortField docs for details of
 why use of this property should be considered a red flag.
 
Default value is null
public DataSourceField[] addedAuditFields
fields of the
  Audit DataSource.
  
 This feature enables the storage of additional information in the Audit DataSource
 alongside the
 standard audit data. In order to do that the audited DataSource needs to declare auditDSConstructor
 referring custom serverConstructor, so that all requests to add data to the Audit DataSource
 could be intercepted allowing to make changes to the new records (obtained using
 DSRequest.getValues()
 server-side API). In this particular use case values for the addedAuditFields need
 to be provided.
  
Example of an audited DataSource (schematically):
  <DataSource audit="true" auditDSConstructor="package.AuditDS">
  <fields>....</fields>
  <addedAuditFields>
    <addedAuditField name="altitude" type="float" />
    <addedAuditField name="longitude" type="float" />
    <addedAuditField name="logCorrelationId" type="text" />
  </addedAuditFields>
  </DataSource>
  
  An example implementation of AuditDS could be as follows:
  
  public class AuditDS extends SQLDataSource {
      public DSResponse executeAdd(DSRequest req) throws Exception {
          // populate additional fields
          Map values = req.getValues();
          values.put("altitude", 54.685);
          values.put("longitude", 25.286);
          values.put("logCorrelationId", "foobar");
          // execute "add" request
          return super.executeAdd(req);
      }
  }
  
 Default value is null
DataSourceFieldpublic DataSourceField[] fields
Each DataSource field can have type, user-visible title, validators, and other metadata attached.
Default value is null
DataSourceFieldpublic java.lang.String ownerIdNullRole
ownerIdField is in force,
 specifies a role that will allow the ownerIdField to take a null value.  Any user
 that has that role  is allowed to create client-initiated "add" and "update" operations that
 specify a null value for the ownerIdField, and the system will persist the null
 value  rather than forcing in the currently authenticated user's user id as it normally would.
 If any client-initiated "add" or "update" request specifies any non-null value  for the
 ownerIdField, the normal behavior of the system will reassert and  the current
 user's user id will be forced into the ownerIdField.  This  allows authorised
 users (ie, those with the necessary role) to choose between saving  public or private records,
 just by sending a null or non-null value for the  ownerIdField.  This property
 has no effect if ownerIdField is not specified. 
 This property can be used in
 conjunction with ownerIdNullAccess to  create the concept of shared, or public, records - see that property's
 documentation  for an example.
 
Default value is null
ownerIdField, 
ownerIdNullAccesspublic int endGap
loading
 progressively, indicates the number of  extra records Smart GWT Server will advertise as being
 available, if it detects that  there are more records to view (see lookAhead).  This property has no 
 effect if we are not progressive-loading.
 Default value is 20
public boolean omitNullDefaultsOnAdd
noNullUpdates
 is also true, indicates that "add"  requests on this DataSource will have null-valued fields
 removed from the request  entirely before it is sent to the server, as opposed to the default
 behavior of  replacing such null values with defaults.
 Default value is false
noNullUpdatespublic java.lang.String nullStringValue
noNullUpdates is set, the
 value to use for any text field that has a null value assigned on an update operation, and does
 not specify an explicit nullReplacementValue.
 Default value is ""
noNullUpdates, 
com.smartgwt.client.docs.serverds.DataSourceField#nullReplacementValuepublic java.lang.Boolean useOfflineStorage
browser-based offline storage, and then use those stored
 responses at a later time if we are offline (ie, the application cannot connect to the server).
   Note that by default we do NOT use offline storage for a dataSource.
 Default value is null
public java.lang.String projectFileKey
projectFileprojectFileLocations from
 the project's configuration (i.e. project.properties, server.properties etc.). For instance, to look
 up the value of project.datasources and use it for projectFileLocations, use
 "datasources" as the  projectFileKey. 
If you specify both
 projectFileKey and  projectFileLocations, then both with be used,
 with the projectFileLocations applied last.
 
Default value is null
public java.lang.Integer logSlowUpdate
"update" operation SQL
 query execution  time threshold in milliseconds, which if exceeded query is identified as
 "slow" and  may be logged under specific logging category.  See logSlowSQL for more details.
 
Default value is null
public java.lang.String defaultBooleanStorageStrategy
serverType:"sql"
 DataSources, sets the default sqlStorageStrategy to use for
 boolean fields where no sqlStorageStrategy has been declared on the field.  Can
 also be set system-wide via the Server_properties setting
 sql.defaultBooleanStorageStrategy, or for a particular database configuration by
 setting sql.dbName.defaultBooleanStorageStrategy (see Admin Console overview for more information on SQL
 configuration). 
 Note that when this property is unset, the default DataSourceField.sqlStorageStrategy strategy is effectively "string".
 
Default value is null
public MultiUpdatePolicy defaultMultiUpdatePolicy
operationBinding.allowMultiUpdate or via the server-side API
 DSRequest.setAllowMultiUpdate().  Default value of null means this DataSource
 will use the system-wide default, which is set via
 datasources.defaultMultiUpdatePolicy in server.properties, and defaults to not allowing
 multi updates for  requests associated with an RPCManager, see MultiUpdatePolicy for details.
 
Default value is null
OperationBinding.allowMultiUpdatepublic java.lang.Boolean useParentFieldOrder
fields from another DataSource  (via inheritsFrom), indicates that the
 parent's field order should be used instead of the order of the fields as declared in this
 DataSource.  New fields, if any, are placed at the end.
 Default value is null
public java.lang.String idClassName
@EmbeddedId you have to specify class name of declared id@IdClass you have to specify class specified in annotation
 declarationDefault value is null
public java.lang.String auditChangedFieldsFieldName
auditing
 enabled, specifies the field name used to store the names of the fields which were updated. 
 If empty string is specified as the field name, the audit DataSource will not store this field.
  Note that this field will only be set for update operations.
 
Default value is "audit_changedFields"
public java.lang.String defaultSortField
serverType
 "sql" only, the name of a field to 
  include in the ORDER BY clause as a means of enforcing a stable sort 
 order, for paged fetches only. 
 This property has no
  effect for non-SQL dataSources, or for non-paged fetches.
  
  Generally speaking, databases make no guarantee about the order of rows in a
  resultset unless an ORDER BY clause was provided.  This is not usually a
  problem if you actually don't care about the row order, but there is a catch if you 
  are using paged fetching: because the pages are fetched using completely different 
  queries, the database is at liberty to use different orderings from one fetch to another,
  and in some cases, with some databases, that is what actually happens.  This leads to 
  broken paging behavior, with some records duplicated and others omitted.
  
Note that it is unusual for a database to change strategies between queries like this; generally speaking, rows are ordered in some kind of natural ordering in the absence of an explicit order - typically insertion order, or by primary key value. However, it does happen, and is more likely with some database products than others.
  This property only has an effect if forceSort is in effect for the fetch 
  operation.  See below for DataSource- and operation-level options, but ordinarily this
  is arranged by setting the forceSort property for the current database 
  configuration in your server.properties file:
    # Given this database definition
    sql.MyDB.database.type: mysql
 
    # Either of these settings will enable automatic sorting
    sql.MyDB.forceSort: true
    # Or
    sql.mysql.forceSort: true
  
  Note, the defaultSortField should ideally provide a unique ordering: so
  for an employee table, payroll number would be preferable to employee name.  A 
  non-unique ordering will usually be sufficient to ensure stablity of ordering from one
  query to the next, because it will usually ensure that the database is forced to use the
  same index in each case.  However, the database may still choose to order rows 
  differently within the confines of the non-unique ordering, so only a unique ordering 
  is guaranteed to ensure stability.
  
 Fields of type creatorTimestamp are
 also good 
  candidates for this purpose - assuming you have a suitable index in place, and assuming
  sorting by temporal values does not introduce performance problems with your database of
  choice - as they are often unique or near-to-unique, and they reflect the insertion 
  order, which is the "natural ordering" in some (not all) databases.
  
  Note that this automatic sorting does not interfere with the ordinary sorting that your
  application may do: it is applied in addition to any application sort order.  So
 if your application imposes no sort
 order, the resultset will 
  be sorted by the defaultSortField; if your application requests a sort 
  order of, eg, "state" then "city", the resultset will be ordered by "state", then 
  "city", and then the defaultSortField
  
  If forceSort is enabled and you do not provide a 
  defaultSortField for a given database, Smart GWT will instead use the
 primaryKey field(s).  If
 the dataSource does not 
  define a primaryKey, we will just use the dataSource's first defined 
  field.  Recommendation: Unless you have a reason to explicitly declare a 
  defaultSortField, we recommend that you leave it undefined for any 
  DataSource that declares a primaryKey (and we recommend that all
  dataSources declare a primaryKey).  The primaryKey field is
  usually the ideal candidate for this purpose, because it is unique and almost certainly
  indexed.
  
  Note that forceSort is enabled by default for PostgreSQL, because this 
  product is known to be less likely to retain a stable sort order between two similar,
  unordered queries.
  
DataSource level and 
 operationBinding level. 
 However, this facility is 
  only provided to allow complete configurability in unusual cases.  Generally speaking, 
  if a database requires ordering for correct behavior with paged fetches, it 
  always requires ordering for correct behavior with paged fetches; you can't 
  ordinarily pick and choose which tables or which individual fetches need to be ordered.
  That said, there may be real world cases where a database that normally requires ordering for correct behavior, nevertheless has individual cases where that is not required - maybe on tables that have only a single index, or in cases where there are no joins involved, or maybe in other circumstances related to how that specific database product works internally. Or again, there may be unusual individual cases where a database that ordinarily works fine for paged fetches without requiring ordering, needs to apply an ordering.
  We provide the DataSource- and operation-level forceSort flags to allow 
  you to work around or take advantage of these database-specific quirks.  However, use of
  them should be considered a red flag because they might cause problems if things change
  in the future (new database release, change in the underlying query, addition of a 
  foreignKey relation at the database level, etc).
 
Default value is null
public java.lang.Boolean autoDeriveSchema
inherit from the special
 super-DataSource.  This allows you to 
  auto-derive schema from existing metadata, whilst still being able to override any or all
  of it as required. By default additional derived field definitions are placed at the end,
 but that can be changed by useParentFieldOrder flag.
 Also, derived field
 definitions may be hidden using showLocalFieldsOnly.
  This property has a different implementation depending upon the 
 serverType of the
 DataSource:
schemaBean.  If 
  schemaBean is not specified, derive the schema from the columns in the SQL 
 table specified in tableName. 
 More information on SQL DataSources 
  is hereschemaBean property.  If no
 such thing exists, derive the schema from
 the Hibernate mapping or Java class specified in the beanClassName
  property (this allows you to specify schema and mapping separately, in the unusual 
  circumstance that you have a need to do so).  Note that the "mappings" referred to here
  can mean either .hbm.xml files or annotated classes; both are supported.
  If neither of these is successful, derive the schema from the underlying SQL table 
 specified in tableName.  More
 information on Hibernate DataSources is
  hereschemaBean 
  property.  If the schemaBean property is not defined, derive the schema from the 
 annotated JPA class named in the beanClassName property (as with 
  Hibernate, this allows you to specify schema and mapping separately if you need to do 
  so).  JPA DataSource generation relies on annotations (the orm.xml mapping file is not 
 supported).  More information on JPA DataSources is hereschemaBean property.  If no
 such bean is found (or Spring is not 
  present), attempt to instantiate an object whose fully-qualified class name is the value
  in the schemaBean property.  If one of these approaches succeeds, we derive
  the schema from the discovered object (by treating it as a Java Bean and assuming that 
  each one of its getters corresponds to a like-named field in the DataSource).  More 
 information on custom DataSource implementations is here.primary key
  fields at the top.
  DataSource types when we use an SQL table as a
 source of metadata
  for a SQL or Hibernate DataSource:
  | SQL type | DataSource type | 
|---|---|
| CHAR, VARCHAR, LONGVARCHAR, TEXT, CLOB | text | 
| BIT, TINYINT, SMALLINT, INTEGER, BIGINT, DECIMAL*, NUMBER** | integer | 
| REAL, FLOAT, DOUBLE, DECIMAL*, NUMBER** | float | 
| DATE | date | 
| TIME | time | 
| TIMESTAMP | datetime | 
| BLOB, BINARY, VARBINARY, LONGVARBINARY | binary | 
The following table shows how Java types are derived into DataSource types when we use an unannotated Java class (Spring bean, Hibernate mapping or POJO) as a source of metadata for a SQL, Hibernate or custom DataSource:
| Java type | DataSource type | 
|---|---|
| boolean, Boolean | boolean | 
| char, Character, String, Reader | text | 
| byte, short, int, long, Byte, Short, Integer, Long, BigInteger | integer | 
| float, double, Float, Double, BigDecimal | float | 
| Enum | enum (see discussion below) | 
| InputStream | binary | 
| java.sql.Date, java.util.Date, java.util.Calendar | date | 
| java.sql.Time | time | 
| java.sql.Timestamp | datetime | 
  Finally, this table shows how Java types are derived into DataSource types when we use an 
  annotated class as a source of metadata.  Note annotated classes are necessary for JPA
  DataSources, but you can choose to use them for other types of DataSource as well.  
  For Hibernate DataSources, this is very worthwhile because Hibernate will also make use
  of the annotations as config, meaning you don't need to specify .hbm.xml 
  files.  For SQL and custom DataSources, there is no benefit at the persistence level, 
  but it may still be worthwhile because the use of an annotated class gives us better 
  metadata and allows us to generate a better, closer-fitting autoDerive DataSource than 
  we can from examination of SQL schema or plain Java Beans:
  
| Java type | DataSource type | 
|---|---|
| boolean, Boolean | boolean | 
| char, Character, String, Reader | text | 
| byte, short, int, long, Byte, Short, Integer, Long, BigInteger | integer | 
| float, double, Float, Double, BigDecimal | float | 
| InputStream | binary | 
| java.util.Date (with Temporal set to DATE), java.sql.Date | date | 
| java.util.Date (with Temporal set to TIME), java.sql.Time | time | 
| java.util.Date (with Temporal set to TIMESTAMP), java.util.Calendar, java.sql.Timestamp | datetime | 
| Enum (with Enumerated set to STRING) | enum (see discussion below) | 
| Enum (with Enumerated set to ORDINAL) | intEnum (see discussion below) | 
| Field with Lob annotation | binary | 
| Field with GeneratedValue annotation | sequence, if the field is an integer type (see discussion below) | 
If the metadata source is an SQL table:
DatabaseMetaData.getPrimaryKeys() APIprimaryKey: trueDatabaseMetaData.getColumns() is inspected.  If the metadata includes
      IS_AUTOINCREMENT=YES, we mark the corresponding field as 
      type="sequence".  This information should be reliably provided by 
      databases that implement "auto-increment" or "identity" column types, such as MySQL
      or Microsoft SQL ServerResultSetMetaData obtained by running a dummy query on the table.  If 
      the isAutoIncrement() API returns true for that column, we mark the 
      corresponding field as type="sequence"TYPE_NAME in the column metadata.  If it is "serial", this means the 
      column is a PostgreSQL "serial" or "serial8" type column.  Postgres does not 
      transparently implement auto-increment columns, but it does provide this serial 
      type, which causes the column to be implicitly bound to an underlying sequence.  So
      this type causes us to mark the field type="sequence", and we also set
 implicitSequence
 trueCOLUMN_DEF in the column metadata.  If this contains the token "$$ISEQ"
      and ends with "NEXTVAL", this means the column is an Oracle "GENERATED AS IDENTITY" 
      column.  This type of column was introduced in Oracle 12c and is conceptually 
      exactly the same thing as the Postgres "serial" column described above.  We treat 
      it the same way: mark it type="sequence" and 
      implicitSequence="true"server.properties flag auto.derive.integer.pk.always.sequence
      is true, we mark the field as type="sequence".ds.xml 
      file:
   <DataSource serverType="sql" tableName="myTable" autoDeriveSchema="true">
     <fields>
       <!-- This field was incorrectly marked as a sequence -->
       <field name="notASeq" type="integer" />
       <!-- This field was incorrectly marked as an integer when it should be a sequence -->
       <field name="isASeq" type="sequence" />
     </fields>
   </DataSource>  
  If the metadata source is Hibernate mappings described in a .hbm.xml file:
  
If the metadata source is an annotated object (whether JPA, Hibernate or just an annotated POJO):
@Id annotation is is marked as a primaryKey (this 
      differs from the Hibernate .hbm.xml file case because that is specific 
      to Hibernate, which does support composite keys, but not by specifying multiple 
      <id> tags.  Annotations are supported, via annotated POJOs, for any kind of 
      persistence strategy, so multiple @Id fields are perfectly valid)@GeneratedValue annotation is either marked as 
      type="sequence" (if it is an integer type) or as 
 autoGenerated="true"Enum properties in plain or annotated classes, 
  as well as setting the field type as noted in the above tables, we also generate a 
  valueMap for the field, based on the Enum members.  
  
  For cases where we generate a field of Smart GWT type "enum" (see the above tables), 
  the keys of the valueMap are the result of calling name() on each member
  of the underlying Java Enum (in other words, its value exactly as declared in its 
  enum declaration).  For cases where we generate a field of Smart GWT type "intEnum",
  the keys of the valueMap are strings representing the ordinal number of each member 
  in the Java Enum - "0", "1", etc. Note that this behavior will be overriden by 
 DataSource.enumTranslateStrategy if both are set.
  
  In both of these case, the display values generated for the valueMap are the result 
  of calling toString() on each Enum member.  If that gives the same 
  value as calling name(), the value is passed through 
  DataTools.deriveTitleFromName(), which applies the same processing rules
 as getAutoTitle() to derive a more
 user-friendly display value.
  
schemaBean implies autoDeriveSchema, because it has no other 
  purpose than to name the bean to use for auto-derived schema.  Thus, if you specify
  schemaBean you do not need to specify autoDeriveSchema as well
  (though it does no harm to do so).  However, tableName and 
  beanClassName can be validly specified without implying 
  autoDeriveSchema, so in those cases you must explicitly specify 
  autoDeriveSchema.
  
  The underlying super-DataSource is cached in server memory, so that it does 
  not have to be derived and created each time you need it.  However, the cache manager 
  will automatically refresh the cached copy if it detects that the deriving DataSource 
  has changed.  Thus, if you change the metadata your DataSource is deriving (if, for 
  example, you add a column to a table), all you need to do is touch the 
  .ds.xml file (ie, update its last changed timestamp - you don't actually
  have to change it) and the cached copy will be refreshed next time it is needed.
  
  When autoDeriveSchema is set, SQLDataSource will automatically discover foreignKeys and
  deliver table and column name information to the client in hashed form so that two
  DataSources that are linked by native SQL foreign keys will automatically discover each
  other if loaded into the same application, and set 
 foreignKey automatically. 
 Because the table and column 
  names are delivered as cryptohashes, there is no information leakage, but regardless,
  the feature can be disabled via setting datasource.autoLinkFKs to false in
 server.properties.  This hashed linkage
 information is
 delivered to the client in properties tableCode and
 DataSourceField.fkTableCode/fkColumnCode
 
Default value is null
public java.lang.Boolean useSequences
serverType:"sql", this flag indicates  whether any fields of type "sequence" should be backed by a 
 native database sequence (if the flag is true) or an auto-increment/identity column (if it is
 false).  It is only applicable in cases where the database in use supports both  approaches,
 and Smart GWT supports both strategies with that particular database. For most
 databases, even those that natively support either approach, Smart GWT uses  one or the other,
 and this cannot be configured. Right now, the only supported database is Microsoft SQL Server. If you specify this flag on a non-SQL DataSource or if any database other than SQL Server is in use, the flag is simply ignored.
 If not set, this flag defaults to the
 server.properties setting  sql.{dbName}.use.sequences, which in turn
 defaults to false.
 
Default value is null
public java.lang.Boolean allowAdvancedCriteria
AdvancedCriteria on fetch or filter type operations.  This
 property may be set to false to indicate that this dataSource does not support 
 advancedCriteria. See supportsAdvancedCriteria() for further information on this.  NOTE: If you specify
 this property in a DataSource descriptor  (.ds.xml file), it is enforced on the
 server.  This means that if you run  a request containing AdvancedCriteria against a DataSource
 that advertises itself as  allowAdvancedCriteria:false, it will be rejected.
 
Default value is null
OperationBinding.allowAdvancedCriteriapublic java.lang.String schema
 Defines the name of the schema we use to qualify the tableName in generated SQL.  If you do
 not provide this property, table names will not be qualified in generated  SQL, and thus the
 default schema will be used.  Support for multiple schemas (or schemata) varies quite
 significantly across the supported databases, as does the meaning of the  phrase "default
 schema".  In addition, some databases allow you to override the default  schema in the JDBC
 connection URL, which is a preferable approach if all your tables are  in the same
 (non-default) schema. 
The following table provides information by product:
| Product | Notes | 
| DB2 | Arbitrarily named schemas are supported. The default schema is named after the connecting user, though this can be overridden by specifying the "currentSchema" property on the JDBC connection URL | 
| DB2 for iSeries | Arbitrarily named schemas are supported. "Schema" is synonymous with "library". The default schema depends on the setting of the "naming" connection property. When this is set to "sql", behavior is similar to other DB2 editions: the default schema is named after the connecting user, unless overridden by specifying a library name in the JDBC connection URL. When "naming" is set to "system", the schema of an unqualified table is resolved using a traditional search of the library list; the library list can be provided in the "libraries" property | 
| Firebird | Firebird does not support the concept of schema
 at all - all "schema objects" like tables  and indexes belong directly to the database.  In
 addition, Firebird actively rejects  qualified table names in queries as syntax errors;
 therefore, you should not set the schemaproperty for a DataSource that
 will be backed by a Firebird database | 
| HSQLDB | Arbitrarily named schemas are supported. The default schema is auto-created when the database is created; by default it is called "PUBLIC", but can be renamed. It is not possible to set the default schema in the JDBC connection URL | 
| Informix | Informix databases can be flagged as "ANSI mode" at creation time. ANSI-mode databases behave similarly to DB2 for schema support: arbitrarily named schemas are supported, and the default schema is the one named after the connected user. Non-ANSI databases have no real schema support at all. It is not possible to set the default schema in the JDBC connection URL with either type of database | 
| Microsoft SQL Server | Prior to SQL Server 2005, schema support is similar to Oracle: "schema" is synonymous with "owner". As of SQL Server 2005, schema is supported as a separate concept, and a user's default schema can be configured (though it still defaults to a schema with the same name as the user). It is not possible to set the default schema in the JDBC connection URL | 
| MySQL | MySQL does not have a separate concept of "schema"; it treats the terms "schema" and "database" interchangeably. In fact MySQL databases actually behave more like schemas, in that a connection to database X can refer to a table in database Y simply by qualifying the name in the query. Also, because schema and database are the same concept in MySQL, overriding the "default schema" is done implicitly when you specify which database to connect to in your JDBC connection URL | 
| Oracle | Arbitrarily named schemas are not supported; in Oracle, "schema" is synonymous with "user", so each valid user in the database is associated implicitly with a schema of the same name, and there are no other schemas possible. It is possible to refer to tables in another user's schema (assuming you have the privileges to do so) by simply qualifying the table name. The default schema is always implied by the connecting user and cannot be overridden. | 
| Postgres | Arbitrarily named schemas are supported. Rather than the concept of a "default schema", Postgres supports the idea of a search path of schemas, whereby unqualified table references cause a search of the list of schemas in order, and the first schema in the path is the "current" one for creation purposes. Unfortunately, there is no way to specify this search path on the JDBC connection URL, so the default schema comes from the user definition, ultimately defaulting to the default "public" schema | 
Default value is null
public int nullIntegerValue
noNullUpdates is set, the
 value to use for any integer field that has a null value assigned on an update operation, and
 does not specify an explicit nullReplacementValue.
 Default value is 0
noNullUpdates, 
com.smartgwt.client.docs.serverds.DataSourceField#nullReplacementValuepublic boolean audit
When auditing is enabled, every time a DSRequest modifies this DataSource, a Record is added to the audit DataSource that shows the record as it existed after the change was made (or for a "remove", the values of the record at the time of deletion). In addition, the audit DataSource has the following additional metadata fields:
"audit_operationType": type of the change ("update", "add" or "remove")
 "audit_modifier":
 username of the user that made the change.  The username is
       determined in the same way that the 
 Declarative Security
 subsystem determines the 
       current user.
 "audit_changeTime": a field of type "datetime" recording
       the timestamp of the change
 "audit_revision": a field of type "sequence" recording a
       simple increasing integer value
 "audit_changedFields": a
 "multiple" field of type
 "string".  For "update"
       operations, records which fields have changed; otherwise, null
  If any of the field names above collide with field names of the DataSource being audited, an integer suffix will also be added, starting with 2 (for example, "audit_modifier2", then "audit_modifier3", etc).
  To omit a data field from the automatically generated audit DataSource, just set
 DataSourceField.audit to false.
  Audit can be disabled for a given DSRequest via
  the server-side API DSRequest.setSkipAudit(), or for a specific operation 
 via the operationBinding.skipAudit setting.
  
 When viewing DataSources in the DataSource
 Navigator, a button will
  be shown at the top of a DataSource's section if it has an audit DataSource to let you
  conveniently open another section to view it.
  
  Note: The DataSource audit feature works only with single row operations; operations with 
 allowMultiUpdate
 enabled are not supported.
  
  The audit DataSource is normally automatically generated, and unless otherwise specified
 with auditDataSourceID,
 the ID of the audit DataSource will be
  audit_[OriginalDSID].  
  
  By default, the automatically generated audit DataSource will be of the same type as the
  DataSource being audited, however, if the DataSource being audited is not already a
 SQLDataSource, we recommend using auditDSConstructor:"sql" to
 use
  a SQLDataSource as the audit DataSource.  This is because a SQLDataSource used an audit
  DataSource will automatically generate a SQL table for storing audit data the first time
  changes are made.  JPA would require manual creation of a Java Bean, and Hibernate requires 
 hbm2ddl.auto=update
 to be set,
  which is widely considered unsafe for production use.
  
 Note that the automatically generated audit DataSource may have additional fields that can be
 populated when new
 audit data is added. See addedAuditFields for more details.
  
  Automatically created audit DataSources can be loaded and queried just like other
  DataSources, using the DataSourceLoader, and using the server-side API
  DataSource.getAuditDataSource().  However, you must load the DataSource
  being audited before loading its automatically created audit DataSource.
  
  Note, that automatic SQL tables creation can be disabled. See 
 autoCreateAuditTable
 for details.
  
 Audit DataSources utilize authenticated username (see the docs for
 RPCManager.getUserId() server-side
 API) to populate the "audit_modifier" field. To enable quick access to additional user
 information, you can associate
  them with a custom "Users" DataSource.
  
 This association can be configured via the framework setting "userDataSource.foreignKey" in the
 "server.properties"
 file, which establishes a relationship between authenticated user and your custom "Users"
 DataSource. Declaring this
 informs the system that the authenticated username is a valid ID for records within a specific
 "Users" DataSource.
 Use the regular DataSourceField.foreignKey format, where, in example below, "UserDS" represents the name of
 the
  related "Users" DataSource, and "userName" serves as the primary key of that DataSource:
  
userDataSource.foreignKey: UserDS.userNameThis configuration enables you to access additional user information seamlessly through built-in framework features like
DSRequest.additionalOutputs and ListGridField.includeFrom when
 reviewing audit data. For instance,
 if "UserDS" declares fields such as "firstName" and "lastName," you can retrieve them using
 additional listGridFields:
  
  {name: "userFirstName", includeFrom: "UserDS.firstName"},
  {name: "userLastName", includeFrom: "UserDS.lastName"}
  
  Alternatively, if you're fetching data manually, you can utilize additionalOutputs as follows:
  additionalOutputs: "userFirstName!UserDS.firstName,userLastName!UserDS.lastName"
  The audit DataSource can also be manually created.  In this case, you can 
  can either follow the naming conventions described above for the ID of the audit DataSource
  and the names of metadata fields, or use the linked properties to assign custom names.  If
  you omit any data fields from the tracked DataSource in your audit DataSource, those fields
 will be ignored for auditing purposes, exactly as though DataSourceField.audit had
  been set to false for an automatically-generated audit DataSource.
  
Also, note that in case of manually defined audit DataSource, if this DataSource is defined so it inherits the audited DataSource, all the audited DataSource's fields will be inherited, this including the primary keys. Since for the audit DataSource the primary key should be the revision field, in order to prevent the audit DataSource having two primary keys, the inherited DataSource's primary key will have to be declared in audit DataSource, but with the primaryKey attribute omitted (as well not being of type "sequence") in the audit DataSource.
Default value is false
public java.util.Map resultTreeClass
ResultTree. This can be set to a custom subclass of ResultTree that, for example, hangs on to extra information necessary for integration with web services.
Default value is null
public java.lang.String guestUserId
ownerIdField if no one  has authenticated. This setting can be overridden at the operationBinding level.
Default value is null
public boolean autoCreateAuditTable
autoCreateAuditTable to true indicates that audit DataSource 
 will automatically create SQL table when auditing is enabled.  Note, that
 autoCreateAuditTable attribute takes effect only if framework setting 
 audit.autoCreateTables in server.properties is set to
 false, which by default is set to true.
 
Default value is true
public java.lang.String serverOnly
serverOnly="true" ensures that it will not be visible
 to the client. Any request through IDACall to this DataSource will return a failure response.
 Only requests which have been initiated on the server-side will be executed against this
 DataSource.
 Default value is null
public java.lang.String description
OpenAPI specification generated by the framework. 
 Markdown is a commonly used syntax, but you may also embed HTML content in a CDATA tag.
 Default value is null
public java.lang.String requiresRole
OperationBinding.requiresRole, but controls access to the DataSource as a whole.
 Default value is null
public boolean compareMetadataForAuditChangeStatus
binary fields on audited DataSources.  When determining
 if a binary field has changed for auditing purposes, should we compare the metadata values (ie,
 the associated _filename and _filesize  fields) or the actual binary
 content?  If you set this flag to false, this will cause  Smart GWT to fetch the existing
 content of any binary field from the database before any update, and then compare it byte by
 byte to the new content.  You should consider if this  will have performance implications for
 your application, particularly if you store large  binary values. 
 Note that value
 comparison of any kind is only performed if the field's  DataSourceField.audit setting is
 "change", but also note that this is the default  setting for binary fields
 
Default value is true
public java.lang.Boolean quoteColumnNames
 In general we
 recommend that you allow the database to use its natural naming scheme when creating tables
 (put more simply, just do not quote column names in the  CREATE TABLE statement);
 if you do this, you will not need to worry about  quoting column names when querying.  However,
 if you are dealing with pre-existing  tables, or do not have control over the database naming
 conventions used, this property may become necessary.  This property may also be necessary if
 you are using field/column names that clash with reserved words in the underlying database
 (these vary by database, but a field called "date" or "timestamp" would have problems with most
 database products) 
 Note: Only applicable to dataSources of serverType "sql".
 
Default value is null
public java.lang.String fileFormatField
fileFormat for FileSource Operations. 
 If the fileFormatField is not configured, then a field named "fileFormat" will be used, if it exists. Otherwise, the DataSource will not track fileFormats -- this may be acceptable if, for instance, the fileFormat is always the same.
The fileFormat is specified according to the extension that would have been used in the filesystem -- for instance, the fileFormat for employees.ds.xml would be "xml".
Default value is null
FileSource overview and related methodspublic java.lang.Boolean trimMilliseconds
 Note that there is no inherent
 support for millisecond precision in Smart GWT widgets; if you need millisecond-precise
 visibility and editability of values in your client,  you must write custom formatters and
 editors (or sponsor the addition of such things to the framework).  Server-side,
 millisecond-precise values are delivered to and obtained from DataSources, so DataSource
 implementations that are capable of persisting and  reading millisecond values should work
 transparently.  Of the built-in DataSource types, the JPA and Hibernate DataSources will
 transparently handle millisecond-precise values as long as the underlying database supports
 millisecond precision, and the underlying  column is of an appropriate type.  The SQLDataSource
 provides accuracy to the nearest second by default; you can switch on millisecond precision
 per-field with the  storeMilliseconds attribute.
 
Default value is null
public DSRequest requestProperties
DSRequests made
 by this DataSource.  This must be set before any DSRequests
 are issued and before any component is bound to the DataSource.  These properties are
 applied before transformRequest()
 is called.
 
Default value is null
public java.lang.String auditTypeFieldName
auditing
 enabled, specifies the field name used to store the operationType (in a field of type "text").  If empty
 string is specified as the field name, the audit DataSource will not store this field.
 Default value is "audit_operationType"
public java.lang.String tableCode
 tableCode and the
 related properties DataSourceField.columnCode, DataSourceField.fkTableCode and
 DataSourceField.fkColumnCode are read-only attributes that are secure and unique cryptographic
 hashes of table and column names used by this DataSource. 
 These properties are used
 automatically by client-side framework code to  link dataSources together by foreign key when a
 foreignKey is not explicitly declared, but is found in the SQL schema via the
 autoDeriveSchema feature.
 
A secure hash is used rather than the actual SQL table or column name for security reasons - sending the actual SQL table or column name to the client could aid in attempted SQL injection attacks.
 This feature can be disabled system-wide via setting
 datasource.autoLinkFKs to false in server.properties.
 
Default value is null
public java.lang.Integer auditChangedFieldsFieldLength
auditing
 enabled, specifies the length of the field used 
  to store the names of the fields which were updated.  See also 
 auditChangedFieldsFieldName
  
  To set the changedFields field length for all DataSources that do not override the default,
  set audit.auditChangedFieldsFieldLength in your server.properties
  file.  For example 
         audit.auditChangedFieldsFieldLength: 512
  
 Default value is 255
public DSInheritanceMode inheritanceMode
serverType
 "sql" and "hibernate", specifies the inheritance  mode to use.  This property has no effect for
 any other type of DataSource.
 Default value is "full"
inheritsFrompublic float nullFloatValue
noNullUpdates is set, the
 value to use for any float field that has a null value assigned on an update operation, and
 does not specify an explicit nullReplacementValue.
 Default value is 0.0
noNullUpdates, 
com.smartgwt.client.docs.serverds.DataSourceField#nullReplacementValuepublic java.lang.String schemaNamespace
WebService.getSchema().
 Default value is null
public java.lang.Boolean qualifyColumnNames
serverType
 "sql", determines whether we qualify column names with table names in any SQL we generate. 
 This property can be overridden on specific operationBindings.
 Default value is true
OperationBinding.qualifyColumnNamespublic java.lang.String auditRevisionFieldName
auditing
 enabled, specifies the field name used to store the revision number for the change (in a field
 of type "sequence").  If empty string is specified as the field name, the audit DataSource will
 not store this field.
 Default value is "audit_revision"
public java.lang.String dataURL
OperationBinding.dataURL.  NOTE: Best practice is to use the same dataURL for
 all DataSources which fulfill DSRequests via the server-side RPCManager API.  Otherwise,
 cross-DataSource operation queuing will
 not be possible.
 
Default value is null
public java.lang.String jsonPrefix
The inclusion of such a prefix ensures your code is not directly executable outside of your application, as a preventative measure against javascript hijacking.
 Only applies to responses formatted as json objects. Does not apply to
 responses returned via scriptInclude type transport.
 Note: If the prefix / suffix served by
 your backend is not a constant, you can use  dataFormat:"custom" instead and
 explicitly parse the prefix out as part of transformResponse().
 
Default value is null
public java.lang.String relatedTableAlias
SQL DataSource that is referred by additional foreign keys, this
 property defines the table alias name to use in generated SQL. If omitted DataSource ID will be used to construct the
 alias.  Aliasing is necessary when the same table appears more than once in a query. In
 addition to use cases described in DataSourceField.relatedTableAlias, this may happen when includeFrom field using
 foreign key defined in
 otherFKs would be included multiple times in a related DataSource. 
 See the "Automatically
 generated table aliases" section of the SQL
 Templating for the complete set of general rules how aliases are generated. Also, see dataSourceField.otherFKs for more
 details and usage samples.
 
Default value is null
public java.lang.String[] projectFileLocations
projectFile<location> tag, e.g.:
 
  
      <projectFileLocations>
          <location>[WEBROOT]/shared/ds</location>
          <location>ds://datasources</location>
      </projectFileLocations>
  
 
  Directories should be specified as absolute paths on the server.  If you
  want to construct a webroot-relative path, then prefix the path with
  [WEBROOT] (unlike in
  server.properties, where you would use
  $webRoot as the prefix).
 
  To specify another DataSource to be used via 
 fileSource operations, use ds://dsName
  (where "dsName" is the name of the other DataSource).
 
  
A projectFile DataSource uses the standard
  fileSource field names: fileName,
  fileType, fileFormat,
  fileContents, fileSize and
  fileLastModified. When defining a projectFile
 DataSource, you can use inheritsFrom with
  a value of "ProjectFile" to inherit definitions for these fields -- e.g.:
 
  
      <DataSource ID="MyDataSources" type="projectFile" inheritsFrom="ProjectFile">
          <projectFileLocations>
              <location>[WEBROOT]/shared/ds</location>
              <location>ds://datasources</location>
          </projectFileLocations>
      </DataSource> 
  
 
  For directory locations, the
  fileName is relative to the directory specified. Note that
  the fileName does not include any extension for type or
  format.  For instance, for "employees.ds.xml", the fileName
  would be "employees", the fileType would be "ds" and the
  fileFormat would be "xml".
 
  
A projectFile DataSource executes the various 
  fileSource operations in the following manner.
  The general rule is that fileName, fileType,
  and fileFormat are treated as primary keys. If files with the
  same combination of those attributes exist in more than one of the
  configured locations, the locations are considered in reverse
  order, with priority given to the location listed last. When modifying
  an existing file, the last location which contains the file will be
  used. When creating a new file, the file will be created in the last
  configured location.
 
  
listFiles 
  listFiles does not 
      recurse into subdirectories. If the same combination of 
      fileName / fileType / fileFormat exists in more than
      one configured location, then the data for fileSize and
      fileLastModified will be taken from the last configured
      location which contains the file.
 
  hasFile
  getFile
  saveFile
  renameFile
  listFiles
      operation will return the file from the other location (as well
      as the renamed file).
 
  removeFile
  listFiles
      operation will return the file from the other location.
 
  projectFile DataSource also responds to the standard
  DataSource operations, in the following manner:
 
  saveFile operation, either adding the file or updating
      an existing file.
 
  listFiles operation. Note that the results will not
      include the fileContents. In order to obtain the
      fileContents, you must use a
      getFile operation.
 
  renameFile operation. Note that this will not update
      the fileContents -- for that, you need to use "add", or
      a saveFile operation. 
 
  removeFile operation.
 
  If you specify both projectFileKey and 
  projectFileLocations, then both with be used, with the
  projectFileLocations applied last.
 
Default value is null
public java.lang.String ownerIdField
DSRequest.isClientRequest() returns true on the server).
  
  Note, the behaviors described below can be affected by the dataSource properties
  ownerIdNullRole and 
 ownerIdNullAccess, so
 please read the documentation 
  for those two properties in conjunction with this article.
 
 
When a new row is added by a client-initiated DSRequest,
 the
  ownerIdField will be automatically populated with the currently
  authenticated user (clobbering any value supplied by the client).
  Client-initiated attempts to update the ownerIdField will also be
  prevented.
 
  
If you wish to set the ownerIdField to a different value via an "add"
  or "update" operation, you can do so in server-side DMI code (possibly
  consulting DSRequest.getClientSuppliedValues() to get the
  value that was clobbered).
 
  
For client-initiated "fetch", "update" or "remove" operations, the
  server will modify client-supplied criteria so that only rows whose
  ownerIdField matches the currently authenticated user can be read,
  updated or deleted.  For built-in DataSource types (SQL, Hibernate and 
  JPA), the additional criteria required to match the ownerIdField 
  field will ignore the prevailing
 textMatchStyle and always use
 exact 
  equality.  If you have a custom or generic DataSource implementation, 
  you will want to do the same thing, to avoid false positives on 
  partial matches (eg, a user with name "a" gets records where the owner
  is any user with an "a" in the name).  You can determine when this is 
  necessary by looking for a DSRequest attribute called 
  "restrictedOwnerIdField".  For example, code similar to the following:
  String restrictedField = (String)dsRequest.getAttribute("restrictedOwnerIdField");
  if (field.getName() != null && field.getName().equals(restrictedField)) {
   // Use exact matching for this field
  } else {
   OK to use the textMatchStyle
  }
  
  Also note, for server-initiated requests, this  automatic criteria-narrowing is not 
  applied; if your application requires server-initiated "fetch", "update" and "remove" 
  requests to be limited to the currently-authenticated user, your code must add the 
  necessary criteria to the request.
 
  The ownerIdField setting can be overridden at the
 OperationBinding.ownerIdField level.
 
  
If ownerIdField is specified,
 requiresAuthentication will
  default to true. If requiresAuthentication is
  explicitly set to false, then unauthenticated users will be
  able to see all records. To avoid this, you can use
 guestUserId to specify a
 default user to
  apply when no one has authenticated.
 
Default value is null
OperationBinding.ownerIdField, 
guestUserIdpublic int lookAhead
loading
 progressively, indicates the number of  extra records Smart GWT Server will read beyond the
 end record requested by the client, in order to establish if there are more records to view. 
 This property has no effect  if we are not progressive-loading.  This property can be
 tweaked in conjunction with endGap
 to change behavior at the end of a dataset.  For example, with the default values of
 lookAhead: 1 and endGap: 20, we can end up with the viewport
 shrinking if we get a case where there really was only one more record (because the client was
 initially told there were 20 more).  This is not a problem per se, but it may be surprising to
 the user. You could prevent this happening (at the cost of larger reads) by setting 
 lookAhead to be endGap+1.
 
Default value is 1
public java.lang.String childrenField
DataSourceField.childrenProperty directly on
  the childrenField object.
 By default the children field will be assumed to be multiple,
  for XML databinding. This implies that child data should be delivered in the format:
  
       <childrenFieldName>
           <item name="firstChild" ...>
           <item name="secondChild" ...>
       </childrenFieldName>
  
  However data may also be delivered as a direct list of childrenFieldName 
  elements:
  
       <childrenFieldName name="firstChild" ...>
       <childrenFieldName name="secondChild" ...>
  
  If you want to return your data in this format, you will need to explicitly set 
  multiple to false in the appropriate dataSource field definition.
 Default value is null
public java.lang.String inheritsFrom
fields from.  Local fields (fields
 defined in this DataSource) are added to inherited fields  to form the full set of fields. 
 Fields with the same name are merged in the same way that databound component fields are merged
 with DataSource fields. 
 The default order of the combined fields is new local fields first
 (including any fields present in the parent DataSource which the local DataSource re-declares),
 then parent fields.  You can set useParentFieldOrder to
 instead use the parent's field order, with new local fields appearing last.  You can set showLocalFieldsOnly to have
 all non-local fields hidden. 
 Note that only fields are inherited - other properties
 such as dataURL and dataFormat are not.  You can use ordinary inheritance, that is, creating a
 subclass of DataSource, in order to share properties such as dataURL across a series of
 DataSources that also inherit fields from each other via inheritsFrom. 
This feature can be used for:
databound
 components. XML Schema
 or other metadata formats databound components to "customizedEmployee". 
 Customizations of fields (including appearance changes, field order, new fields, hiding of
 fields, and custom validation rules) can be added to "customizedEmployee", so that they are
 kept separately from the original field data and have the best possible chance of working with
 future versions of the "employee" dataSource. Default value is null
public java.lang.String auditedDataSourceID
audited DataSource.  Automatically
 populated for auto-generated audit DataSources.
 Default value is varies
public boolean nullBooleanValue
noNullUpdates is set, the
 value to use for any boolean field that has a null value assigned on an update operation, and
 does not specify an explicit nullReplacementValue.
 Default value is false
noNullUpdates, 
com.smartgwt.client.docs.serverds.DataSourceField#nullReplacementValuepublic Date nullDateValue
noNullUpdates is set, the
 value to use for any date or time field that has a null value assigned on an update operation,
 and does not specify an explicit nullReplacementValue.
 Unlike strings and numbers, there is no "natural" choice for a null replacement value for dates. The default value we have chosen is midnight on January 1st 1970, simply because this is "the epoch" - the value that is returned by calling "new Date(0)"
Default value is See below
noNullUpdates, 
com.smartgwt.client.docs.serverds.DataSourceField#nullReplacementValuepublic java.lang.String dataField
DataBoundComponent needs to show a short summary of a
 record. For example, for a DataSource of employees, good choices might be the "salary" field, "hire date" or "status" (active, vacation, on leave, etc).
 Unlike titleField, dataField is not
 automatically determined in the absence of an explicit setting.
 
Default value is null