Field-mapping properties specify which table columns correspond to the component’s container-managed fields, the primary key (which may map to one or several columns), and the timestamp (if used for concurrency control). Before configuring field mappings, make sure that:
You have specified the primary key type, and defined the IDL structure fields if using a multi-column key (or this has been done by the EJB-JAR import process).
You have defined the state type, or it has been defined by the EJB-JAR import process. See “Defining the state datatype”.
If using timestamp columns for concurrency control, you have specified the timestamp column name on the Persistence/General subtab.
Configure field-mapping properties in the Component Properties dialog box, on the Persistence/Field Mapping subtab. This subtab displays a mapping for each container-managed field (based on the state datatype structure fields), the key fields, and the timestamp column (if specified). The initial mappings use default values which you may need to adjust.
Refreshing the field-mapping properties
If you do not see mappings for all fields:
Verify that the state type, primary key, and timestamp have been configured.
Click Ok in the Component Properties dialog box to save the properties.
Reopen the Component Properties dialog box.
The mapping for each field has the form:
column[typespec]
Where:
column is
the database column name. You can use a table prefix, which is required
if the table is not the main table (named in the Table field on
the Persistence/General tab). For example, custinfo.address specifies
the address column in the custinfo table.
All fields that are in the primary key must be mapped to the main table. If you use the default queries in your table mappings, other tables must have key columns with the same name and type as the main table key.
The table name can be a logical table name that does not exist in the database. For example, your database may allow only stored procedure access. In this case, you must define table mappings that describe how to access the data represented by the logical table name. “Configuring table-mapping properties” describes how.
type-spec is the column’s database type, for example:
string(255) not null
or:
binary(255) null
The specified datatype is not necessarily the type used in
the table schema. It can be redefined in the database properties.
For example, binary(255) maps
to varbinary(255) for the database
type Sybase_ASE, and to raw(255) for
Oracle8i. Similarly, string(length) maps
to the appropriate type to define variable or fixed-length character
columns of the specified length. Using the logical type names rather
than actual database types allows you to more easily run the same
configuration against databases of different types. For more information
on these definitions, see Logical column
type definitions in Appendix B, “Repository Properties
Reference,” in the EAServer System Administration
Guide.
If the column is fixed-length binary or character, use one of these types, where length is the field length:
binary(length) fixed length null binary(length) fixed length not null string(length) fixed length string(length) fixed length not null
Overriding the default database column names
For entity beans imported from an EJB-JAR file, the default
field mappings use quoted database column names to avoid conflicts
with database reserved words. In some cases, you may find that the
quoted names exceed the maximum allowed for column names in the
database. In this case, you can modify the column names after deploying,
or add a sybase-easerver-config.xml file to
your EJB-JAR file to set the field mapping properties before deploying. If
you use quoted column names in the XML file, be sure to use the
quote entity (") in
place of quotes in property value strings.
For information on creating an sybase-easerver-config.xml file, see “Using EAServer configuration files in J2EE archives” in Chapter 9, “Importing and Exporting Application Components,” in the EAServer System Administration Guide.
