PATH Documentation > WebObjects 4.5 > Getting Started With WebObjects

Where Do Primary Keys Come From?

Enterprise Objects Framework uses primary keys to identify enterprise objects in memory, and it works best if you never change an enterprise object's primary key from its initial value. Consequently, applications usually generate and assign primary key values automatically instead of having users provide them. For example, the Movies application assigns a movieId value to a new movie when it's created, and the value never changes afterward. The Movies interface doesn't even display movieId values because they aren't meaningful to users of the application.

Enterprise Objects Framework provides several mechanisms for generating and assigning unique values to primary key attributes. By default, Enterprise Objects Framework uses a native database mechanism to assign primary key values. See the chapter "Answers to Common Design Questions" in the Enterprise Objects Framework Developer's Guide for more information.

The Movies application generates primary key values for Movie and Talent objects using the default mechanism, but MovieRole is a special case because:

MovieRole's primary key is compound. The default behavior of generating a primary key value using a native database mechanism works only on simple (not compound) primary keys.
A MovieRole's primary key attributes, movieId and talentId, must match the corresponding attributes in the MovieRole's Movie and Talent objects. The default mechanism generates new, unique values.

Instead of the default mechanism, Enterprise Objects Framework uses primary key propagation to assign primary keys to MovieRole objects. By configuring the Movie's toMovieRole relationship to propagate primary key, the Framework knows to assign a new MovieRole's movieId to the same value as the movieId of the MovieRole's Movie. Similarly, a new MovieRole's talentId is set to the same value as the talentId of the MovieRole's Talent.