Browse Prior Art Database

Partitioning an Entity Using an Entity Whose Primary Key Can Be Changed Disclosure Number: IPCOM000011531D
Original Publication Date: 2003-Feb-27
Included in the Prior Art Database: 2003-Feb-27
Document File: 3 page(s) / 41K

Publishing Venue



Effective use of the Enterprise JavaBeans specification support for unknown primary keys can be achieved by having the primary key support returning itself as a string. The unknown primary key support enables the deployer to change the attributes of the enterprise bean that are used as its primary key. While this support makes it easy to change and use the primary key on the enterprise bean whose primary key is changing, it may also require redeployment of other enterprise beans that use this primary key as part of their primary key and those that hold onto the primary key to represent a relationship. In the case of the relationship, this redeployment would normally be required when there is a need to query the primary key, such as when we need to find all the financial transactions for a particular account. In both cases, in order to remove the requirement to redeploy, the primary key can support a method that turns all of its pieces into a single string that can be mapped into a column. Since this conversion to a single string is done by the primary key. This allows the string to be used in other primary keys. And, in the case of querying a relationship, this method can be called to obtain the string to use in the query, so the enterprise bean with the relationship does not need to be redeployed because of a new primary key.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 35% of the total text.

Page 1 of 3

Partitioning an Entity Using an Entity Whose Primary Key Can Be Changed

  The Enterprise JavaBean specification supports the use of unknown primary keys. While using unknown primary keys doesn't cause problems when simple (single attribute) primary keys are used, when complex keys are use it can cause a ripple of deployments to be required. This occurs both when the primary key is used as part of another primary key (usually due to ownership) and when an enterprise bean holds onto a primary key to represent a relationship and it needs to be queried.

    While simple applications may have simple primary keys, in most business applications, business objects must be owned -- either by other business object or by the business context. A business object's domain identifier, the main piece of the primary key, is only guaranteed to be unique the context of its owner. Thus the primary key of the Business Object needs to consist of its domain identifier and the primary key of its owner. The owner's primary key must be used instead of its domain identifier because the owner is also a business object and as such has the same restriction that its domain identifier is only unique within the context of its owner. For example, an account name ('Assets') is for a particular general ledger, thus the accounts primary key would consist of the general ledgers primary key and the account name ('Assets'). The general ledger may be called 'myGL', but it is the general ledger associated with a particular company, so its primary key would consist of the company's primary key and its identifier ('myGL'). While not always true, for this example we'll assume the company isn't owned and its primary key is simply 'Finance'. Thus to uniquely identify our account we have to use: 'Finance', 'myGL', and 'Assets'.

    When implementing these primary keys with Enterprise JavaBean Container Managed Persistence (CMP), there must be attributes on the entity bean for the pieces of the primary key. In this case the domain identifier, which is typically a string, and the owners primary key, which, because it is unknown, must be of type Object. (However, is typically held as a serializable so that it can be mapped to a binary column). While it can be mapped to a binary column, normally the serializable will be mapped to multiple columns in the database, breaking the owner's primary key into the pieces that make it up in that manner only strings are used in the DB, which enables easy push down of queries. Similarly when holding a primary key to represent a relationship. For example, we may want to find all financial transactions associated with a particular account. Thus the financial transaction would map the three strings in our example to three columns in the database so that the financial transactions that have matching values in all three of these columns can be selected.

    While this implementation works well when the primary keys are well known, it creates a number of problems w...