JDBC Backing Store Configuration : Special Cases

Special Cases
This section explains some cases that may require special handling.
Names that Exceed the DBMS Maximum Column Length
Entity names and entity property names are used by backing store scripts to generate database table and column identifiers. (Entity names can be are overridden by the entity metadata property called Table Name.)
DBMSs put different limits on the length of a database identifier name. For example, in Oracle the maximum length is 30 characters, and in SQL Server the limit is 128 characters.
Note that the generated database identifiers are longer than the TIBCO BusinessEvents identifiers because they contain characters in addition to the TIBCO BusinessEvents identifier.
You can deal with this potential situation in different ways. One way is to configure project settings before you generate the EAR, and the other is configured by running the be-jdbcdeploy utility without modifying the project first. These are explained next.
Allowing the Utility to Generate Aliases for Long Names
When you run the be-jdbcdeploy utility, it generates short aliases for long names. For every entity, property, or state machine whose database identifier name exceeds the maximum length, an entry is created in the generated yourname.aliases file (For example, acme.aliases). This file has no entries if all names are within the DBMS limit.
You can edit the file to specify different short aliases. If you edit the aliases file, you must then run the be-jdbcdeploy utility again, so that your names are used.
The advantage of allowing the scripts to generate aliases is that it is automatic and you are in no doubt that the names will be of a correct length. However these auto-generated names might make it hard to identify what entity they represent, by simply looking at the table names.
The procedure is explained in Task F, Check the Aliases File and Modify Aliases as Desired.
Providing Short Names in the Project, Before Generating the EAR
You can avoid the problem of long names before you begin to configure the backing store; you can specify short database identifiers using metadata properties.
The advantage of this method is that you can choose meaningful names. The disadvantages are that you may not know ahead of time which entities and entity properties require short names, and that you must also ensure that the metadata names are unique across all entities in the ontology.
If entity names are repeated, table names are appended with dollar ($) characters as necessary, for example, D_ORDER, D_ORDER$, D_ORDER$$ and so on.
The procedure is explained in the section Set Metadata Properties for Long Identifiers, as Desired, which is part of Task A, As Needed, Set Entity Metadata Properties
String Properties That Exceed the Maximum Database Column Length
The default column size for String type attributes is 255 characters. If you expect the data length of an entity property to exceed that value, then before you begin backing store setup, open the editor for each such property and set the metadata Max Length field as needed. The utility changes the data type of String attributes with long lengths to CLOB, as appropriate.
Ontology Identifiers That Use Database Key Words
As well as database names that are too long, ontology terms that are key (reserved) words in your DBMS product must also be mapped to an alias. If errors occur when you run the SQL scripts due to key word clashes, examine the errors and add the appropriate words to the key word mapping file.
A provided file (BE_HOME/bin/dbkeywordmap.xml) ships with some basic mappings: start, end, and schema. You can use it as a model.
Unlike the Aliases file, the key word mapping file is not a project-specific file. It is intended to be generally useful across different projects. However, keyword mappings are also added to the aliases file when you run the SQL scripts, so you can also provide project-specific aliases for the generic mappings, if you want to. See JDBC Backing Store Database Configuration Tasks for full details.