Changes for page The EOModel

Summary

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

Details

Page properties

Content

...	...	@@ -1,3 +1,9 @@
	1	+{{info}}
	2	+
	3	+Work in progress! Right now, most of the text is coming from Apple's documentation. We need to change that, and add Wonder and WOLips specific information.
	4	+
	5	+{{/info}}
	6	+
1	1	{{toc}}{{/toc}}
2	2
3	3	= The EOModel =
...	...	@@ -25,7 +25,7 @@
25	25	■ define derived attributes
26	26	■ build database queries in raw SQL
27	27
28		-In an Entity-Relationship model, distinguishable things are known as entities, each entity is defined by its component attributes, and the affiliations, or relationships between entities, are identified (together, attributes and relationships are known as properties). From these three simple modeling objects~-~--entities, attributes, and relationships~-~--arbitrarily complex systems can be modeled.
	34	+In an Entity-Relationship model, distinguishable things are known as entities, each entity is defined by its component attributes, and the affiliations, or relationships between entities, are identified (together, attributes and relationships are known as properties). From these three simple modeling objects~-~-entities, attributes, and relationships~-~-arbitrarily complex systems can be modeled.
29	29
30	30	== Entities ==
31	31
...	...	@@ -66,19 +66,19 @@
66	66
67	67	=== Advanced Entity Inspector ===
68	68
69		-Batch Faulting Size lets you specify the number of faults that should be triggered when you first access an object of this type that is the destination of a to-many relationship. By providing a number in this field, you specify that number of faults of the same entity should be fetched from the data source along with the first fault. This improves performance by minimizing round trips to the data source.
	75	+**Batch Faulting Size** lets you specify the number of faults that should be triggered when you first access an object of this type that is the destination of a to-many relationship. By providing a number in this field, you specify that number of faults of the same entity should be fetched from the data source along with the first fault. This improves performance by minimizing round trips to the data source.
70	70
71		-External Query lets you specify any SQL statement to execute when Enterprise Objects performs an unqualified fetch on the entity. The columns selected by this SQL statement must be in alphabetical order by internal name and must match in number and type with the class properties specified for the entity.
	77	+**External Query** lets you specify any SQL statement to execute when Enterprise Objects performs an unqualified fetch on the entity. The columns selected by this SQL statement must be in alphabetical order by internal name and must match in number and type with the class properties specified for the entity.
72	72
73		-Qualifier is used to specify a restricting qualifier. A restricting qualifier maps an entity to a subset of rows in a table. When you add a restricting qualifier to an entity, it invokes a fetch for that entity to retrieve objects only of the type specified by the restricting qualifier. See "Implementing Single-Table Mapping in a Model" (page 77) for more information on restricting qualifiers.
	79	+**Qualifier** is used to specify a restricting qualifier. A restricting qualifier maps an entity to a subset of rows in a table. When you add a restricting qualifier to an entity, it invokes a fetch for that entity to retrieve objects only of the type specified by the restricting qualifier. See "Implementing Single-Table Mapping in a Model" (page 77) for more information on restricting qualifiers.
74	74
75		-Parent is used to specify a parent entity for the current entity. This field is used to model inheritance. See "Modeling Inheritance" (page 67) for more details on this topic.
	81	+**Parent** is used to specify a parent entity for the current entity. This field is used to model inheritance. See "Modeling Inheritance" (page 67) for more details on this topic.
76	76
77		-Read Only specifies whether the data that's represented by the entity can be altered by your application. This does not lock objects at the database level but rather works at a higher level (in the com.webobjects.eoaccess.EODatabaseContext object) so that if you try to save changes to data that's marked as read only, Enterprise Objects refuses the save and throws an exception.
	83	+**Read Only** specifies whether the data that's represented by the entity can be altered by your application. This does not lock objects at the database level but rather works at a higher level (in the com.webobjects.eoaccess.EODatabaseContext object) so that if you try to save changes to data that's marked as read only, Enterprise Objects refuses the save and throws an exception.
78	78
79		-Cache in Memory specifies that when one record in a table is fetched, the entire table is fetched into memory. Caching an entity's objects allows Enterprise Objects to evaluate queries in memory, thereby avoiding round trips to the data source. This is most useful for read-only entities where there is no danger of the cached data getting out of sync with the data in the data source.
	85	+**Cache in Memory** specifies that when one record in a table is fetched, the entire table is fetched into memory. Caching an entity's objects allows Enterprise Objects to evaluate queries in memory, thereby avoiding round trips to the data source. This is most useful for read-only entities where there is no danger of the cached data getting out of sync with the data in the data source.
80	80
81		-Abstract lets you specify whether the entity is abstract. An abstract entity is one for which no objects are ever instantiated. For example, in the Real Estate database, the User entity is abstract and is never instantiated, whereas entities that inherit from it, such as Agent and Customer, are concrete classes that are instantiated. Like the Parent field, this option is used when modeling inheritance.
	87	+**Abstract** lets you specify whether the entity is abstract. An abstract entity is one for which no objects are ever instantiated. For example, in the Real Estate database, the User entity is abstract and is never instantiated, whereas entities that inherit from it, such as Agent and Customer, are concrete classes that are instantiated. Like the Parent field, this option is used when modeling inheritance.
82	82
83	83	== Attributes ==
84	84
...	...	@@ -114,7 +114,7 @@
114	114	~1. An entity named EOAdaptorNamePrototypes, where AdaptorName is the name of the adaptor for your model. WebObjects 5.2 includes an adaptor for JDBC data sources and an adaptor for JNDI data sources. So you can create a prototype entity called either EOJDBCPrototypes or EOJNDIPrototypes, depending on the adaptor you use.
115	115	2. An entity named EOPrototypes.
116	116
117		-To create a prototype attribute, first create a prototype entity~-~--an entity named either EOAdaptorNamePrototypes or EOPrototypes~-~--and add an attribute to it. Figure 3-3 shows an attribute in a prototype entity. It shows all the values that prototype attributes can define: column name, value class, external type, and value type.
	123	+To create a prototype attribute, first create a prototype entity~-~-an entity named either EOAdaptorNamePrototypes or EOPrototypes~-~-and add an attribute to it. Figure 3-3 shows an attribute in a prototype entity. It shows all the values that prototype attributes can define: column name, value class, external type, and value type.
118	118
119	119	To assign a prototype attribute to an attribute, reveal the Prototype column in table mode, and select a prototype attribute from the pop-up menu. The prototype attributes that appear in the pop-up list in the Prototype column include prototype attributes defined in any entity in any model in the application's model group, which includes the current model.
120	120
...	...	@@ -273,7 +273,7 @@
273	273
274	274	== EO Inheritance ==
275	275
276		-One of the issues that may arise in designing your enterprise objects~-~--whether you're creating a schema from scratch or working with an existing database schema~-~--is the modeling of inheritance relationships.
	282	+One of the issues that may arise in designing your enterprise objects~-~-whether you're creating a schema from scratch or working with an existing database schema~-~-is the modeling of inheritance relationships.
277	277
278	278	In object-oriented programming, it's natural to think of data in terms of inheritance. A Customer object, for example, naturally inherits certain characteristics from a Person object, such as name, address, and phone number. In inheritance hierarchies, the parent object or superclass is usually rather generic so that less generic subclasses of a related type can easily be added. So, in addition to the Customer object, a Client object also naturally derives from a Person object.
279	279
...	...	@@ -335,6 +335,10 @@
335	335
336	336	Single-table mapping results in tables that have columns for all of the attributes of each entity in the inheritance hierarchy. It also results in many null row values. While these aren't really disadvantages, they may conflict with some database design philosophies.
337	337
	344	+=== Using Inheritance in Entity Modeler ===
	345	+
	346	+To use Inheritance in your model, you first need to create your base entity. When done, right-click on the entity and select Subclass. A dialog will appear and will ask you to specify which kind of Inheritance you want to use, which entity is the parent and the name of the new (child) entity. When selecting Vertical or Single-Table Inheritance, you can also specify the qualifier (type = XX) in that dialog (you can do that part later too).
	347	+
338	338	== EOGenerator ==
339	339
340	340	== Handling Blob Data ==