Common Programming Errors
This section discusses some of the more subtle issues you need to be aware of when building enterprise object classes.
In this section:
Overriding equals or hashcode
Immutable Primary Keys
Primary Keys and Allows Null
Overriding equals or hashcode
Don’t override equals or hashcode. Enterprise Objects uses the methods equals and hashcode in enterprise object classes to perform object comparisons and other functions. You should not implement either method in your enterprise object classes.
A common mistake is to use equals to compare enterprise objects. Avoid doing this and instead compare the global IDs of enterprise objects using equals. The code in “Listing 3-3” provides an example.
Listing 2-3 Comparing two enterprise objects using equals on their global IDs
if ((editingContext.globalIDForObject(enterpriseObject1)). |
equals(editingContext.globalIDForObject(enterpriseObject2))); |
Immutable Primary Keys
Enterprise Objects does not support changeable primary keys. That is, you cannot change the value of a row’s primary key. A common, though poor, design pattern in database application development is to store meaningful business data as primary keys such as driver license numbers.
What if a value like this changes? If you try to change the value of a row’s primary key in Enterprise Objects, the enterprise object that represents that row will never be allowed to save in the Enterprise Objects application. The optimistic locking mechanism in Enterprise Objects always throws an exception if a row’s primary key changes. So, don’t mix columns that include meaningful business data with columns that are used to define database structure.
If you encounter a situation in which you must change an object’s primary key, the recommended procedure is to create a new enterprise object of the same type, copy the data from the original object into the new object, and delete the original object.
Primary Keys and Allows Null
In some cases, you need to set the allows null characteristic of a primary key attribute to true. This situation often occurs in master-detail relationships in which a detail object is added to the relationship but is not immediately saved to the database. You usually set a primary key’s allows null characteristic in the advanced attribute inspector in EOModeler.
What a primary key’s allows null characteristic means, however, may be unclear. No primary key is ever allowed to be null in a database that Enterprise Objects accesses. When you allow null for a primary key, validation within Enterprise Objects doesn’t throw an exception when a new enterprise object is created and is used within the application before being inserted into the database; on the way to the database, Enterprise Objects generates a value for the primary key regardless of its allows null characteristic.
Last updated: 2007-07-11
  |
||
|
|
|
|
| ||
Get information on Apple products.
Visit the Apple Store online or at retail locations. 1-800-MY-APPLE Copyright © 2007 Apple Inc. All rights reserved. | Terms of use | Privacy Notice |