Specifying a properties file with the idresgen utility
Use an alternative Java properties file to describe which columns of a primary entry should be used as lookups for tables, which require the identifier of a primary row. This definition takes precedence over the unique index resolution method.
The default properties file is IdResolveKeys.properties, but you can modify it or specify your own file when invoking the idresgen utility.
The IdResolveKeys.properties is located in the following directory:
- WC_installdir/properties
- WCDE_installdir\properties
If you do not place this file is in the current directory when you run the igresgen utility, you can place it in a directory defined in the classpath environment variable. You can also specify the full path to this file.
To change IdResolveKeys.properties:
- Copy IdResolveKeys.properties from the WC_installdir/properties directory and save it to the WC_userdir/instances/instance/xml directory.
- Make any necessary changes to this new file.
Use the properties file as follows:
- Use a properties file to generate identifiers
- Use a properties file with compound keys
- Use a properties file with cascaded primary keys
Use a properties file to generate identifiers
In the following example, resolve identifiers ADDRBOOK_ID and ADDRESS_ID for ADDRBOOK and ADDRESS records respectively. The identifiers for the MEMBER records are already known. Each record requires a valid identifier for the WebSphere Commerce database. In addition, the ADDRBOOK_ID in the ADDRESS record requires the identifier from the primary table to satisfy its foreign-key constraint.
<MEMBER MEMBER_ID="100" TYPE="U" STATE="1" /> <MEMBER MEMBER_ID="101" TYPE="U" STATE="1" /> <ADDRBOOK MEMBER_ID="100" DISPLAYNAME="Friends" Actual value of the DISPLAYNAME column DESCRIPTION="All my friends" TYPE="P" /> <ADDRESS ADDRBOOK_ID="@Friends" Refers to the ADDRBOOK using the DISPLAYNAME value as a lookup MEMBER_ID="101" NICKNAME="Bob" ADDRESS1="15 Brave Developers St." CITY="Toronto" ZIPCODE="A0A0A0" COUNTRY="Canada" STATUS="P" />You need a properties file to identify which columns in the primary row will be used by the relationship rows in resolving the identifier for the foreign-key column. The following procedure ensures that parsing of the preceding file proceeds correctly.
In IdResolveKeys.properties, specify the following:
NAMEDELIMITER=@ SELECTDELIMITER=: ADDRBOOK=@DISPLAYNAME:DISPLAYNAME ADDRESS=@NICKNAME:NICKNAME
- NAMEDELIMITER and SELECTDELIMITER set the delimiters used throughout the properties file, and they must be used consistently.
- ADDRBOOK=@DISPLAYNAME:DISPLAYNAME states that when an address-book record is received, the identifier for the address-book row is created.
- The DISPLAYNAME field is extracted from the input record and used to form an association to the new identifier. The DISPLAYNAME string is used to match the address-book row DISPLAYNAME and resolve the identifier needed by the foreign key.
Use the previous input example, in which the DISPLAYNAME is Friends, assume that the identifier created for this record is 12951. The DISPLAYNAME is used as a key look-aside for 12951. Processing continues with the next record, ADDRESS, where ADDRBOOK_ID has the form of "@..." (which indicates that what follows the delimiter is to be used for looking up the address-book identifier). The string matches the DISPLAYNAME, and 12951 is returned and placed in the ADDRBOOK_ID attribute.
<MEMBER MEMBER_ID="100" TYPE="U" STATE="1" /> <MEMBER MEMBER_ID="101" TYPE="U" STATE="1" /> <ADDRBOOK ADDRBOOK_ID="12951" Generated primary key MEMBER_ID="100" DISPLAYNAME="Friends" Value of ADDRBOOK DISPLAYNAME unchanged DESCRIPTION="All my friends" TYPE="P" /> <ADDRESS ADDRESS_ID="13051" Generated primary key ADDRBOOK_ID="12951" ADDRESS refers to correct ADDRBOOK MEMBER_ID="101" NICKNAME="Bob" ADDRESS1="15 Brave Developers St." CITY="Toronto" ZIPCODE="A0A0A0" COUNTRY="Canada" STATUS="P" />
Use a properties file with compound keys
A key made up of more than two columns is a compound key. You can define a compound-key lookup in the properties file by specifying both NAMEDELIMITER and SELECTDELIMITER followed by the field names. To have the lookup criteria for ADDRBOOK records be the compound of the display name and the member ID, for example, specifying the following in the properties file:
ADDRBOOK=@DISPLAYNAME@MEMBER_ID:DISPLAYNAME MEMBER_IDthen the following XML input-file fragment:
<ADDRBOOK MEMBER_ID="100" DISPLAYNAME="Friends" ADDRBOOK "Friends" of MEMBER 100 DESCRIPTION="All my friends" TYPE="P" /> <ADDRBOOK MEMBER_ID="101" DISPLAYNAME="Friends" ADDRBOOK "Friends" of MEMBER 101 DESCRIPTION="All my friends" TYPE="P" /> <ADDRESS ADDRBOOK_ID="@Friends@100" Lookup the primary key for ADDRBOOK "Friends" of MEMBER 100 MEMBER_ID="101" NICKNAME="Bob" ADDRESS1="15 Brave Developers St." CITY="Toronto" ZIPCODE="A0A0A0" COUNTRY="Canada" STATUS="P" />would yield the following after resolution:
<MEMBER MEMBER_ID="100" TYPE="U" STATE="1" /> <MEMBER MEMBER_ID="101" TYPE="U" STATE="1" /> <ADDRBOOK ADDRBOOK_ID="12951" ADDRBOOK of interest MEMBER_ID="100" DISPLAYNAME="Friends" DESCRIPTION="All my friends" TYPE="P" /> <ADDRBOOK ADDRBOOK_ID="12952" MEMBER_ID="101" DISPLAYNAME="Friends" DESCRIPTION="All my friends" TYPE="P" /> <ADDRESS ADDRESS_ID="13051" ADDRBOOK_ID="12951" ADDRESS refers to correct ADDRBOOK MEMBER_ID="101" NICKNAME="Bob" ADDRESS1="15 Brave Developers St." CITY="Toronto" ZIPCODE="A0A0A0" COUNTRY="Canada" STATUS="P" />
Use a properties file with cascaded primary keys
The primary table STOREENT defines a primary key STOREENT_ID. STORE, a foreign table referencing STOREENT, defines a primary key STORE_ID that is a foreign key to the primary table STOREENT. This means that the value of STORE_ID must be one of the STOREENT_ID values. STORE_ID, the primary key of the foreign table STORE, therefore has a dual role: primary and foreign.
Let us assume that another table, CONTRACT, is a foreign table on STORE and that the foreign key for CONTRACT, STORE_ID, references the primary key STORE_ID in STORE. The STORE table is therefore a primary table for the CONTRACT table.
Because the STORE table's STORE_ID is referenced from the STOREENT_ID rather than created, the idresgen utility does not create an internal-alias and ID-value association for the STORE table. When the CONTRACT table tries to resolve the STORE_ID from the STORE table, it gets the empty value.
Because of this special condition, explicitly specify the creation of the internal alias by creating an entry in the properties file. In IdResolveKeys.properties, specify the following:
"STORE=@STORE_ID:STORE_ID"This forces the idresgen utility to:
- Create the internal-alias and ID-value association while resolving the STORE_ID as a foreign reference
- Use the association while resolving the STORE_ID for the CONTRACT table
Use the STORE=@STORE_ID:STORE_ID entry in the properties file and the following XML input-file fragment:
<STOREENT IDENTIFIER="Out Fashions" MEMBER_ID="-2000" STOREENT_ID="@storeent_id_1" TYPE="G" /> <STORE STORE_ID="@storeent_id_1" STOREGRP_ID="1" STORELEVEL="store_level" /> <CONTRACT CONTRACT_ID="@contract_id_1" STATE="0" STORE_ID="@storeent_id_1" />would yield the following after resolution:
<STOREENT IDENTIFIER="Out Fashions" MEMBER_ID="-2000" STOREENT_ID="10501" TYPE="G" /> <STORE STORE_ID="10501" STOREGRP_ID="1" STORELEVEL="store_level" /> <CONTRACT CONTRACT_ID="@contract_id_1" STATE="0" STORE_ID="10501" />Related concepts
Related tasks
Related reference