web server - Borland Technical Publications
web server - Borland Technical Publications web server - Borland Technical Publications
Container-Managed Persistence in Borland Enterprise Server CASE 2: a bidirectional one-to-many relationship. SPECIAL_INFO CUSTOMER_NO Next, we finish the entry by providing its other half, the SpecialInfo bean. Since this is a mono-directional relationship, we don't need to specify any table elements. We only need add the following, defining the other half of the relationship and its source: SpecialInfo Here, we have a Customer entity bean with a primary key, CUSTOMER_NO, that is also a foreign key in an Order entity bean. We want the Borland EJB Container to manage this relationship. The Customer bean uses a field called “orders” that links a customer to his orders. The Order bean uses a field called “customers” for linking in the reverse direction. First, we define the relationship and its source for the first direction: setting up the mapping for a Customer's orders. Customer orders Then, we add the table references to specify the relationship between the tables. We're basing this relationship on the CUSTOMER_NO column, which is a primary key for Customer and a foreign key for Orders: CUSTOMER CUSTOMER_NO ORDER CUSTOMER_NO Chapter 15: Entity Beans and Table Mapping for CMP 2.0 137
Container-Managed Persistence in Borland Enterprise Server CASE 3: a many-tomany relationship. We're not quite done with our relationship, though. Now, we need to complete it by specifying the relationship role for the other direction: Customer customers ORDER CUSTOMER_NO CUSTOMER CUSTOMER_NO . . If you define a many-to-many relationship, you must also have the CMP engine create a cross-table which models a relationship between the left table and the right table. Do this using the element, whose XML is: You may name this cross-table whatever you like using the element. The two elements correspond to columns in the left and right tables whose relationship you wish to model. For example, consider two tables, EMPLOYEE and PROJECT, which have a many-to-many relationship. An employee can be a part of multiple projects, and projects have multiple employees. The EMPLOYEE table has three elements, an employee number (EMP_NO), a last name (LAST_NAME), and a project ID number (PROJ_ID). The PROJECT table contains columns for the project ID number (PROJ_ID), the project name (PROJ_NAME), and assigned employees by number (EMP_NO). 138 BES Developer’s Guide
- Page 97 and 98: Client view of an enterprise bean L
- Page 99 and 100: Client view of an enterprise bean E
- Page 101 and 102: Managing transactions Managing tran
- Page 103 and 104: Support for JNDI Support for JNDI T
- Page 105 and 106: EJB to CORBA mapping A CORBA progra
- Page 107 and 108: 96 BES Developer’s Guide
- Page 109 and 110: Application Client architecture Pac
- Page 111 and 112: Document Type Definitions (DTDs) my
- Page 113 and 114: Support of references and links The
- Page 115 and 116: Use of Manifest files Use of Manife
- Page 117 and 118: 106 BES Developer’s Guide
- Page 119 and 120: Sessions in secondary storage If yo
- Page 121 and 122: 110 BES Developer’s Guide
- Page 123 and 124: Container-managed persistence and R
- Page 125 and 126: Implementing an entity bean Generat
- Page 127 and 128: Container-Managed Persistence in Bo
- Page 129 and 130: Container-Managed Persistence in Bo
- Page 131 and 132: Setting Properties Setting Properti
- Page 133 and 134: Setting Properties into a BLOB. The
- Page 135 and 136: Setting Properties Automatic table
- Page 137 and 138: 126 BES Developer’s Guide
- Page 139 and 140: Container-managed persistence and R
- Page 141 and 142: Container-Managed Persistence in Bo
- Page 143 and 144: Container-Managed Persistence in Bo
- Page 145 and 146: Container-Managed Persistence in Bo
- Page 147: Container-Managed Persistence in Bo
- Page 151 and 152: Container-Managed Persistence in Bo
- Page 153 and 154: 142 BES Developer’s Guide
- Page 155 and 156: Setting Properties J2EE 1.3 Entity
- Page 157 and 158: Setting Properties Figure 16.2 Edit
- Page 159 and 160: Setting Properties Table 16.1 ejb.m
- Page 161 and 162: Setting Properties Table 16.3 Table
- Page 163 and 164: Setting Properties Security Propert
- Page 165 and 166: Aggregate Functions in EJB-QL Selec
- Page 167 and 168: Support for ORDER BY Support for OR
- Page 169 and 170: Overriding SQL generated from EJB-Q
- Page 171 and 172: Container-managed data access suppo
- Page 173 and 174: 162 BES Developer’s Guide
- Page 175 and 176: Generating primary keys from a cust
- Page 177 and 178: Implementing primary key generation
- Page 179 and 180: Transaction manager services Consis
- Page 181 and 182: Transaction manager services When t
- Page 183 and 184: Transaction manager services Follow
- Page 185 and 186: Declarative transaction management
- Page 187 and 188: Declarative transaction management
- Page 189 and 190: JDBC API Modifications JDBC API Mod
- Page 191 and 192: Handling of EJB exceptions Applicat
- Page 193 and 194: 182 BES Developer’s Guide
- Page 195 and 196: Client View of an MDB Client View o
- Page 197 and 198: Clustering of MDBs This is yet anot
Container-Managed Persistence in <strong>Borland</strong> Enterprise Server<br />
CASE 2: a bidirectional<br />
one-to-many<br />
relationship.<br />
<br />
SPECIAL_INFO<br />
CUSTOMER_NO<br />
<br />
<br />
<br />
<br />
Next, we finish the entry by providing its other half, the SpecialInfo<br />
bean. Since this is a mono-directional relationship, we don't need to specify any table<br />
elements. We only need add the following, defining the other half of the relationship<br />
and its source:<br />
<br />
<br />
SpecialInfo<br />
<br />
<br />
<br />
<br />
Here, we have a Customer entity bean with a primary key, CUSTOMER_NO, that is also a<br />
foreign key in an Order entity bean. We want the <strong>Borland</strong> EJB Container to manage this<br />
relationship. The Customer bean uses a field called “orders” that links a customer to his<br />
orders. The Order bean uses a field called “customers” for linking in the reverse<br />
direction. First, we define the relationship and its source for the first direction: setting up<br />
the mapping for a Customer's orders.<br />
<br />
<br />
<br />
<br />
Customer<br />
<br />
<br />
orders<br />
Then, we add the table references to specify the relationship between the tables. We're<br />
basing this relationship on the CUSTOMER_NO column, which is a primary key for Customer<br />
and a foreign key for Orders:<br />
<br />
<br />
CUSTOMER<br />
<br />
CUSTOMER_NO<br />
<br />
<br />
<br />
ORDER<br />
<br />
CUSTOMER_NO<br />
<br />
<br />
<br />
<br />
<br />
Chapter 15: Entity Beans and Table Mapping for CMP 2.0 137