Changes for page The EOModel
Last modified by Pascal Robert on 2012/03/10 15:42
From version 30.1
edited by Pascal Robert
on 2012/03/10 10:30
on 2012/03/10 10:30
Change comment:
There is no comment for this version
To version 31.1
edited by Pascal Robert
on 2012/03/10 08:27
on 2012/03/10 08:27
Change comment:
There is no comment for this version
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -190,10 +190,10 @@ 190 190 ==== Delete Rule ==== 191 191 192 192 The options in the Delete Rule section specify what to do when the source object of a relationship is deleted. There are four options: 193 -■ **Nullify**disassociates all destination objects from the source object by removing references to them. So, when an Agent object is deleted, its related Customer objects are not deleted but the Customer objects' references to Agent are nullified (the entry in the join table is set to null).194 -■ **Cascade**deletes all objects that are the destination of a relationship whose source is deleted. So, when an Agent object is deleted, all of its related Customer objects are also deleted.195 -■ **Deny**refuses the deletion if a source object has any destination objects. So, if an Agent object has any Customer objects, deleting the Agent object is denied. In order for the deletion of the Agent object to succeed, its destination objects (Customer objects) must either be deleted or changed to something other than destination objects of the Agent object.196 -■ **No Action**deletes the destination object but does not remove any back references to the source object. So, if a Customer object is deleted, its reference to its Agent object is not removed. Using this option may result in dangling references in the data source.193 +■ Nullify disassociates all destination objects from the source object by removing references to them. So, when an Agent object is deleted, its related Customer objects are not deleted but the Customer objects' references to Agent are nullified (the entry in the join table is set to null). 194 +■ Cascade deletes all objects that are the destination of a relationship whose source is deleted. So, when an Agent object is deleted, all of its related Customer objects are also deleted. 195 +■ Deny refuses the deletion if a source object has any destination objects. So, if an Agent object has any Customer objects, deleting the Agent object is denied. In order for the deletion of the Agent object to succeed, its destination objects (Customer objects) must either be deleted or changed to something other than destination objects of the Agent object. 196 +■ No Action deletes the destination object but does not remove any back references to the source object. So, if a Customer object is deleted, its reference to its Agent object is not removed. Using this option may result in dangling references in the data source. 197 197 198 198 === Tips === 199 199 ... ... @@ -247,11 +247,11 @@ 247 247 248 248 You can set up an EOModel so that Enterprise Objects automatically invokes a stored procedure for these operations on an entity: 249 249 250 - **Insert**to insert a new object into an entity251 - **Delete**to delete an object from an entity252 - **Fetch All**to fetch all objects in an entity253 - **Fetch w/ PK**to fetch the object in an entity with a particular primary key254 - **Get PK**to generate a new primary key for an entity250 +Insert to insert a new object into an entity 251 +Delete to delete an object from an entity 252 +Fetch All to fetch all objects in an entity 253 +Fetch w/ PKto fetch the object in an entity with a particular primary key 254 +Get PK to generate a new primary key for an entity 255 255 256 256 The stored procedures you enter in the Stored Procedure Inspector must correspond to a stored procedure in the model. If you created the model from an existing data source and chose the Ask About Stored Procedures option in the wizard, stored procedures are already added to the model. If this is not the case, however, you can add stored procedures to the model using the Add Stored Procedure command from the Property menu. 257 257 ... ... @@ -261,21 +261,21 @@ 261 261 262 262 For each of the operations, if the stored procedure associated with an operation returns a value, Enterprise Objects ignores the return value. 263 263 264 -For **Fetch All**operations, the stored procedure must not take any arguments and it should return a result set for all the objects in the corresponding entity. The rows in the result set must contain values for all the columns Enterprise Objects would fetch if it were not using the stored procedure, and it must return them in alphabetical order.264 +For Fetch All operations, the stored procedure must not take any arguments and it should return a result set for all the objects in the corresponding entity. The rows in the result set must contain values for all the columns Enterprise Objects would fetch if it were not using the stored procedure, and it must return them in alphabetical order. 265 265 266 266 That is, the stored procedure should return values for primary keys, foreign keys used in class property joins, class properties, and attributes used for locking. These values must be returned in alphabetical order with regard to the attributes with which they are associated. For example, consider a Listing entity that has the attributes listingID, bedrooms, and sellingPrice. A stored procedure that fetches all the Listing objects should return the value for a listing's number of bedrooms, then its listingID, and then its selling price. 267 267 268 -For **Fetch w/ PK**operations, the stored procedure must take an "in" argument for each of the entity's primary key attributes (most entities have a single primary key attribute). The argument names must match the names of the entity's primary key attributes. For example, a Listing entity has a single primary key attribute named listingID, so the stored procedures argument as defined in the model must also be listingID.268 +For Fetch w/ PK operations, the stored procedure must take an "in" argument for each of the entity's primary key attributes (most entities have a single primary key attribute). The argument names must match the names of the entity's primary key attributes. For example, a Listing entity has a single primary key attribute named listingID, so the stored procedures argument as defined in the model must also be listingID. 269 269 270 -A **Fetch w/ PK**operation stored procedure should return a result set containing the row that matches the primary key passed in by the argument. The row must be in the same form as rows returned by the Fetch All operation.270 +A Fetch w/ PK operation stored procedure should return a result set containing the row that matches the primary key passed in by the argument. The row must be in the same form as rows returned by the Fetch All operation. 271 271 272 -For **Insert**operations, the stored procedure must take an "in" argument for each of the corresponding entity's attributes. The argument names must match the names of the corresponding EOAttribute objects.272 +For Insert operations, the stored procedure must take an "in" argument for each of the corresponding entity's attributes. The argument names must match the names of the corresponding EOAttribute objects. 273 273 274 -For **Delete**operations, the stored procedure must take an "in" argument for each of the entity's primary key attributes. The argument names must match the names of the primary key attributes as in a Fetch w/ PK operation stored procedure.274 +For Delete operations, the stored procedure must take an "in" argument for each of the entity's primary key attributes. The argument names must match the names of the primary key attributes as in a Fetch w/ PK operation stored procedure. 275 275 276 -For **Get PK**operations, the stored procedure must take an "out" argument for each of the entity's primary key attributes. The argument names must match the names of the primary key attributes as in a Fetch w/ PK operation stored procedure.276 +For Get PK operations, the stored procedure must take an "out" argument for each of the entity's primary key attributes. The argument names must match the names of the primary key attributes as in a Fetch w/ PK operation stored procedure. 277 277 278 - **Insert**,**Delete**, and**Get PK**operations should not return a result set.278 +Insert, Delete, and Get PK operations should not return a result set. 279 279 280 280 == EO Inheritance == 281 281 ... ... @@ -347,23 +347,10 @@ 347 347 348 348 == EOGenerator == 349 349 350 -For many years, a tool called **EOGenerator** was used by many developers to use the Generation Gap Pattern on the Enterprise Objects. Since **EOGenerator** was using a ObjectiveC <-> Java that Apple killed in Mac OS X 10.5, a 100% Java tool, **Veogen**, was added to WOLips, so by default everyone is now using it. 351 - 352 -By using **Veogen**, when you create a new EO entity in your data model, two Java class will be generated, one called //EntityName.java, and the other EntityName.java. The class starting with the underscore will be regenerated every time you modify the entity in the model, if you want to change something in that class, you need to change the template. The class without the underscore is the place where you can add other variables or methods.// 353 - 354 354 == Handling Blob Data == 355 355 356 356 == Connection Dictionary == 357 357 358 -In each EOModel, you can store one or many database configurations. A database configuration consists of the prototype selection for your database (MySQL, H2, etc.), the adaptor (99% of the time, it's JDBC), the URL (JDBC connection string), the username and password to connect to the datastore, the driver (JDBC driver name) and the name of the EOAdaptor plugin. 359 - 360 -If you wish 361 - 362 -#dbConnectUserGLOBAL= 363 -#dbConnectPasswordGLOBAL= 364 -dbConnectURLGLOBAL = jdbc:h2:file:,,/politimo 365 -dbConnectPluginGLOBAL = H2PlugIn,, 366 - 367 367 == Runtime Selection of the Connection Dictionary and Prototypes == 368 368 369 369 == Debugging JDBC Connections and Jdbc2info ==