Changes for page The EOModel

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -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 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
	250	+**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/ PK** to 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,6 +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	+
350	350	== Handling Blob Data ==
351	351
352	352	== Connection Dictionary ==