xsd.noorm-generator-configuration.xsd Maven / Gradle / Ivy
Java package name for generated Bean source files.
Java package name for generated Enum source files.
Java package name for generated Service / DAO source files.
Services, resp. DAOs generated by NoORM are singletons. By default, the services
or DAOs are instantiated right after class loading and provided by the class method
"getInstance".
Alternatively, class instantiation can be delegated to a dependency injection framework
like Spring. By specifying parameter serviceInterfacePackageName, the service generator
is directed to omit the in-class singleton implementation and generate appropriate
interfaces for every service, resp. DAO in the given package.
Regular expression to filter tables and views for Bean generation.
Regular expression to filter tables and views for Enum generation.
Regular expression to filter (database) packages for service generation.
Primary key generation for new records being inserted into the database can be based
on a numeric ID column and an sequence. Sequences are not tied to a table
by definition, so associating a table with a sequence is done using this property
list. Note that the association TABLE_NAME/SEQUENCE_NAME can either be done on a per
table basis, or using one or more regular expressions to specify a mapping rule like
"TBL_(.*)" -> "SEQ_$1" (This rule would map TBL_PRODUCT to SEQ_PRODUCT, for example).
Some database tables may have a couple of fields, which are identically in name
and purpose (i.e.: "ID", "UPDATED_BY", "UPDATED_AT", etc.).
For those tables, it can be helpful to apply some functionality for these columns
by the means of a custom interface.
Using this parameter, it is possible to specify the name of the interface, which
is (automatically) implemented by the generated bean. Keep in mind that the
required method names for the specified interface (with respect to possible renaming)
must exist in the generated class.
Note that the interface name must be fully qualified, when it does not reside in
the same package, which has been configured with parameter "beanJavaPackage".
Like in all other mappings, regular expressions may be used to specify the
mapping.
Regular expression to filter tables and views for inline sequence value generation.
When sequences are used to generate primary key values for tables, the sequence
values are retrieved from the database using a separate SQL statement. This is
the most flexible approach concerning performance for bulk inserts and the provision
of the generated values for the application (i.e., the beans subject to insertion
are modified by setting the primary key values on the fly).
However, for tables typically having single inserts only (no bulk inserts) with a
sequence increment of 1, it can be preferable to inline the sequence generation to
avoid the extra database round-trip to get the next sequence value. For single
row inserts, NoORM can return the updated bean (primary key value), too.
This parameters allows for a flexible specification of the beans / tables subject to
inline sequence value generation using a regular expression.
The default naming scheme for the generated classes follows standards and conventions
for names used in databases and names used for Java classes (upper CamelCase).
While database names are usually in upper-case, using the underscore as delimiter
between parts of the name (e.g. "ORDER_DETAIL"), Java names use a capitalized first
character of the name part without delimiter instead (e.g. "OrderDetail").
This parameter can be used to override this mechanism by specifying a regular expression
for the mapping between the database name and the Java name.
This setting applies to the bean generator and the enum generator.
The default naming scheme for the generated attributes follows standards and conventions
for names used in databases and names used for Java classes (lower CamelCase).
While database names are usually in upper-case, using the underscore as delimiter
between parts of the name (e.g. "ORDER_ID"), Java names use a capitalized first
character of the name part without delimiter instead (e.g. "OrderId").
This parameter can be used to override this mechanism by specifying a regular expression
for the mapping between the database name and the Java name.
This setting applies to the bean generator and the enum generator.
To generate Enums from database tables, NoORM must now, which table column should be
used for the enums constant type generation. Typically, a table with constant content
has a column with a code or denominator in uppercase letters, which uniquely
identifies the row.
Use this parameter to map tables, resp. views to this column name.
Concurrency control can be based on optimistic locking. To identify the version column,
a mapping from the table-name to the version column should be specified. Dependent on
how specific the column-names are with respect to the table-names, one or more
mappings are required. In case of a unique name of the version column for all tables,
one simple rule like ".*" -> "VERSION" is sufficient.
Concurrency control can be based on optimistic locking.
When no version column is available for the tables subject to optimistic locking,
the complete pre-change image of the row is used to determine database changes, which
have occurred in the meantime. The tables listed here are subject to this type of
optimistic locking.
(Do not use both available types of optimistic locking simultaneously).
The database metadata does not provide unambiguous information for the primary
key of a view (for tables, this information is available). When the intended use of a
view includes DML operations (which requires the view to contain one and only one
key-preserved table) or data access with the PageableBeanList, NoORM needs a key to
uniquely distinguish the records of this view.
Use this parameter to specify the column name of the key used for a given view.
Typically, this key is the primary key of the single key-preserved table contained in
the view definition.
Using the signature of a stored procedure to generate code does not provide any hint,
if the returned data is limited to a single row (which in turn changes
the signature of the generated Java code, instead of a List a single Bean is returned).
Use this parameter to specify a regular expression matching all procedure names
subject to single row retrieval.
Large query results can be mapped into a PageableBeanList to provide efficient
access to the data by loading the full record only for the requested page.
Beans generated from database entities are often subject to data enrichment in
the service layer utilizing the bean data. One option to add additional data to
the bean is the generic (generated) bean property "auxiliaryData". However, some
data consumers may require data provided in a flat bean without nested data
(i.e., the additional data is available using standard bean properties).
As an alternative approach to the auxiliary data property, the user may create
a subclass for the generated bean with additional bean properties. To utilize
this inherited bean classes, the generated services using the originally generated
class should use the subclass. This parameter allows to replace occurrences of the
originally generated bean classes in the generated services/DAOs with the subclass.
Note that the subclass must be fully classified.
The implementation of methods "equals" and "hashCode" for the generated beans raises
the same questions intensively discussed for JPA entities. In particular, three options
are available: do not implement these methods at all, implement them based on the
technical ID, i.e. the primary key, or implement them based on some business-id.
The latter is not applicable for generated code, since we do not have the required
insight into the semantics of the bean/table to decide on a business-id.
Thus, options one and two remain and this option can be used to choose one. Note that
this option is set to true by default (i.e. methods equals and hashCode are
automatically implemented based on the primary key).
When multiple data sources are used, the data source name as configured in the NoORM
configuration file is used to identify different data sources. To specify the data
source used for the subsequent statements, one can either set the data source explicitly
using DataSourceProvider.setActiveDataSource, or one can specify the data source name
here. Note that for explicit transaction handling, one still have to specify the data
source name.
The NoORM query declaration is intentionally much simpler than most other approaches
to specify alternatives to original SQL. While specifications like the JPA 2.0 criteria
API aim to cover most of the capabilities of SQL, this approach consequently follows
the paradigm to move database-centric functionality to the database.
In particular, this means that the complexity of an SQL statement should be implemented
inside the database using views. Following this approach, it is almost always possible
to reduce the query declaration for automatic Java code generation to a single entity
(table, view), the columns subject to the where-conditions (concatenated by "AND") and
the operators used for the columns in the where-conditions.
The Java code generator defines for every database type a default Java type, which is
used in the generated classes for attributes and method parameters (e.g. NUMBER ->
java.lang.Long).
However, this mapping may not be suitable for certain situations. This configuration
parameter provides a flexible way to define custom type mappings.
Note that the database type depends on the database system and is not checked for validity,
but simply compared against the database types as retrieved from the database metadata.
So, an invalid database type has simply no effect.
The specified Java type however is checked for existence by the code generator, but not for
validity with respect to a proper data conversion in the JDBC driver used.
Generic attribute for names.
Generic attribute for regular expressions.
Generic mapping element.
A list of automatically generated query declarations.
Query declarations provide a convenient and simple way to specify SQL queries without the need
to explicitly write SQL code. However, query declarations are not designated to replace SQL code
of arbitrary complexity, but only to provide an efficient method to specify rather primitive SQL
queries using a single entity only and a list of WHERE conditions concatenated by "AND".
The name of the database entity (table or view) to query against.
The name of the database entity (table or view), which is the base for the returning
type. When parameter "tableName" is a view, the desired return type may be only one of
the tables contained in the view.
The (Java) method name for the generated code (if omitted, NoORM automatically
generates a method name. This is typically suitable, if not too many query columns
are defined. For many query columns, manual method name specification if preferable).
The name of the Java class to be generated (Optional, by default NoORM generates one
single class named "DeclaredQueries" for all declared queries. By explicitly specifying
a class name it is possible to group the declared queries).
Indicates, whether the generated query is expected to return a single row only.
This will change the method return type from "java.util.List" to the respective
type (default is false).
Indicates, whether NoORM should acquire a lock for the retrieved rows (by appending
the "FOR UPDATE" clause to the generated SQL).
Note that this option is only useful when used in an explicitly managed transaction
(user-managed), otherwise an exception is thrown.
Indicates, whether the generated API for this query should include a FilterExtension.
The FilterExtension provides support for paging and sorting for the given query.
Note that this functionality is not available (and does not make sense either) for
single row queries.
A query column is a WHERE condition consisting of a database column name from the used entity
with an operator for the construction of the full WHERE condition.
This enumeration is a predefined list of supported relational operators available for the
construction of WHERE conditions. Note that the operators "IS_NULL" and "IS_NOT_NULL" are
unary, i.e., they do not need the provision of a parameter to compare against (will be
automatically reflected by the code generator).
Operator "IN" corresponds to the SQL operator "IN", meaning that not only one single value
is used for the WHERE condition, but a list. The generated Java code will expect a
java.util.List with elements of the column type (resp. mapped Java type) in the finder
interface.
A list of custom type mappings (see type "customTypeMapping").
A single type mapping with its application scope.
The scope of the custom type mapping can be specified on a per parameter basis using
regular expressions to identify the parameter(s) for the application of the custom
type mapping.
The scope of the custom type mapping can be specified on a per table basis using
regular expressions to identify the table(s) for the application of the custom
type mapping.
To apply the specified type mapping to all tables (and columns), a wildcard
expression can be used (".*").
The scope of the custom type mapping can be specified on a per column basis using
regular expressions to identify the column(s) for the application of the custom
type mapping.
The database (source) type of the custom type mapping. This is the SQL standard or
vendor specific type declaration like "INTEGER" or "NUMBER". Note that only the base
type declaration is used to identify an attribute applicable for a custom type
mapping (e.g. fractions of numeric types are ignored, but through the usage of the
filter regex for tables and columns it is usually no problem to restrict the mapping
to the column(s) of choice).
The Java type for the custom type mapping (see enumeration "javaType")
The database (source) type of a custom mapping. This is the type used in the generated
Java code for the column annotation of the bean attributes.
The available types resemble the types declared in java.sql.Types.
With Java 8, type handling has become more comfortable by introducing enum JDBCTypes.
Since this enum is not available in earlier Java versions, it has been copied for the
current NoORM release.
The Java (destination) type of a custom mapping. This is the type used in the generated
Java code for bean attributes, enum attributes or service method parameters.
Java types from package "java.lang.*" do not need to get fully specified (i.e., "Long",
"Double", etc., is sufficient), other types must be fully specified
(e.g. "java.math.BigDecimal").
© 2015 - 2024 Weber Informatics LLC | Privacy Policy