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:

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:

  1. Copy IdResolveKeys.properties from the WC_installdir/properties directory and save it to the WC_userdir/instances/instance/xml directory.

  2. Make any necessary changes to this new file.

Use the properties file as follows:

 

 

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

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_ID

then 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:

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