Changes for page Leveraging the Power of EOF

Summary

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

Details

Page properties

Content

...	...	@@ -1,4 +1,4 @@
1		-{{toc}}{{/toc}}
	1	+{{toc/}}
2	2
3	3	= Leveraging the Power of EOF =
4	4
...	...	@@ -8,7 +8,7 @@
8	8
9	9	There are many objects involved in retrieving data in an Enterprise Objects application. The ones you'll most commonly work with are introduced here.
10	10
11		-EOFetchSpecification A fetch specification provides a description of what data to retrieve from a data source. A fetch specification always includes the name of an entity~-~--in Enterprise Objects, a single database fetch operation is always done from the perspective of a particular entity. A fetch specification usually includes a qualifier~-~--specific criteria to look for when searching the database. A fetch specification can also include a sort ordering, which specifies that the result set should be sorted in a particular way.
	11	+EOFetchSpecification A fetch specification provides a description of what data to retrieve from a data source. A fetch specification always includes the name of an entity~-~-(% style="text-decoration: line-through;" %)in Enterprise Objects, a single database fetch operation is always done from the perspective of a particular entity. A fetch specification usually includes a qualifier(%%)~-~-specific criteria to look for when searching the database. A fetch specification can also include a sort ordering, which specifies that the result set should be sorted in a particular way.
12	12
13	13	EOQualifier A qualifier is often included in a fetch specification to provide criteria for a particular database fetch. There are a number of different kinds of qualifiers, some of which map to a SQL expression such as AND or OR. A qualifier is commonly compound~-~--that is, a qualifier often consists of multiple qualifiers.
14	14
...	...	@@ -15,7 +15,7 @@
15	15	EOSortOrdering A sort ordering is often included in a fetch specification to specify that the fetch's result set should be sorted in a particular way.
16	16
17	17	EOEditingContext In Enterprise Objects, a fetch almost always takes place within an object workspace called an editing context.
18		-Other objects are involved in a fetch specification, such as EODatabaseContext and EOAdaptorChannel, but you rarely need to interact with these objects programmatically.
	18	+ Other objects are involved in a fetch specification, such as EODatabaseContext and EOAdaptorChannel, but you rarely need to interact with these objects programmatically.
19	19
20	20	=== Flow of Data During a Fetch ===
21	21
...	...	@@ -33,8 +33,8 @@
33	33
34	34	When an EOCooperatingObjectStore receives a request to fetch data from a data source, it invokes objectsWithFetchSpecification on its EODatabaseContext object to do the work. When a database context receives this fetch request, it fetches a number of rows from the database, transforms them into enterprise objects (in most cases), and registers them as needed with the EOEditingContext that initiated the chain of objectsWithFetchSpecification invocations.
35	35
36		-A database context uses an EODatabaseChannel to do all this. That object in turn uses an EOAdaptorChannel object to communicate directly with data sources and model-level objects~-~--EOEntity, EOAttribute, EORelationship~-~--that are necessary to perform the fetch.
37		-Within EODatabaseContext, fetching occurs in two major steps:
	36	+A database context uses an EODatabaseChannel to do all this. That object in turn uses an EOAdaptorChannel object to communicate directly with data sources and model-level objects~-~-(% style="text-decoration: line-through;" %)EOEntity, EOAttribute, EORelationship(%%)~-~-that are necessary to perform the fetch.
	37	+ Within EODatabaseContext, fetching occurs in two major steps:
38	38
39	39	* A database context uses a database channel to select the rows in the database for which objects are being fetched. It does this using the EODatabaseChannel method selectObjectsWithFetchSpecification, which takes as an argument the fetch specification that originated in the editing context.
40	40
...	...	@@ -85,13 +85,13 @@
85	85	* A new enterprise object is instantiated by an EOEntityClassDescription object.
86	86
87	87	* The enterprise object is initialized from a row snapshot. Only objects that are class properties or client-side
88		-class properties are included. Faults are created for any references to relationships defined in the EOModel.
	88	+ class properties are included. Faults are created for any references to relationships defined in the EOModel.
89	89
90	90	=== Faulting and Relationship Resolution ===
91	91
92	92	One of the most powerful and useful features of Enterprise Objects is that it automatically resolves the relationships defined in a model. It does this in part by delaying the actual retrieval of data—and delaying communicating with the database—until the data is needed, a feature of Enterprise Objects called faulting. Faulting happens in two phases: the creation of a placeholder object (a fault) for the data to be fetched, and fetching the data when it's needed (firing a fault).
93	93
94		-When Enterprise Objects fetches an object, it examines the object's relationships as defined in the EOModel in which the object (entity) is defined. It then creates objects (faults) representing the destinations of the fetched object's relationships. For example, if you fetch a Listing object that has an agent relationship and an address relationship, faults are created for the destination of those relationships, which are an Agent object and an Address object. The Agent and Address objects are not fetched (their rows in the database are not accessed) until their data is actually needed.
	94	+When Enterprise Objects fetches an object, it examines the object's relationships as defined in the EOModel in which the object (entity) is defined. It then creates objects (faults) representing the destinations of the fetched object's relationships. For example, if you fetch a Listing object that has an agent relationship and an address relationship, faults are created for the destination of those relationships, which are an Agent object and an Address object. The Agent and Address objects are not fetched (their rows in the database are not accessed) until their data is actually needed.
95	95
96	96	Fetching is resource-intensive and often recursive—fetching the destination object of one enterprise object may require fetching that destination object's destination objects, and so on until all of the interrelated rows in the database have been retrieved. To avoid this waste of time and resources, the destination objects are created as stand-ins, which are referred to as faults.
97	97
...	...	@@ -121,7 +121,7 @@
121	121
122	122	== Data Freshness ==
123	123
124		-When developing Enterprise Objects applications, one of the most common challenges is providing users with the freshest possible data while maintaining reasonable application performance. In a multiuser database environment, there is a risk of update conflicts occurring in which multiple users access and attempt to change the same set of data simultaneously. Providing fresher data to users can help alleviate update conflicts.
	124	+When developing Enterprise Objects applications, one of the most common challenges is providing users with the freshest possible data while maintaining reasonable application performance. In a multiuser database environment, there is a risk of update conflicts occurring in which multiple users access and attempt to change the same set of data simultaneously. Providing fresher data to users can help alleviate update conflicts.
125	125
126	126	The first thing to understand when dealing with the issue of data freshness is to understand when Enterprise Objects uses cached data and when it fetches data from a database. In most cases, if an editing context asks an enterprise object for its data, it receives cached data unless:
127	127