Changes for page The EOModel

Last modified by Pascal Robert on 2012/03/10 15:42

From 24.1 to 23.1 From 30.1 to 29.1

From version 29.1

edited by Pascal Robert
on 2012/03/10 10:30

Change comment: There is no comment for this version

To version 24.1

edited by Pascal Robert
on 2011/02/27 12:28

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

Page properties

Content

@@ -1,11 +9,3 @@
--{{info}}
--
--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.
--
--{{/info}}
--
--{{toc}}{{/toc}}
--
  = The EOModel =
  While it may seem obvious, data modeling is perhaps the most important phase of WebObjects application development. Data models form the foundation of your business logic and business logic forms the core of your application. Good business logic is essential to building effective applications, so it follows that good data models are essential to the success of the applications you build. Most importantly, data modeling plays a crucial role in object-relational mapping, the process in which database records are transposed into Java objects.
@@ -19,19 +19,19 @@
  Data models in Enterprise Objects reflect the earliest decisions about what data users see and how they are allowed to interact with data. This is because an important part of data modeling is deciding which entities and attributes are visible to clients and editable by clients. So by including data modeling as an early part of the design process, you can simplify future implementation details.
  WebObjects provides you with a great tool for object-relational mapping called EOModeler. It allows you to
--■ build data models either from scratch or by analyzing preexisting data sources using reverse engineering
--■ add and customize entities (tables) and attributes (columns)
--■ form relationships between entities
++■ build data models either from scratch or by analyzing preexisting data sources using reverse engineering
++■ add and customize entities (tables) and attributes (columns)
++■ form relationships between entities
  ■ form relationships across multiple models
--■ generate SQL from a model to create or update a data-source schema based on the model
--■ generate Java classes from a model in which you can add custom business logic
--■ use stored procedures within data models
++■ generate SQL from a model to create or update a data-source schema based on the model
++■ generate Java classes from a model in which you can add custom business logic
++■ use stored procedures within data models
  ■ graphically build fetch specifications for retrieving data
--■ flatten attributes and relationships
--■ define derived attributes
--■ build database queries in raw SQL
++■ flatten attributes and relationships
++■ define derived attributes
++■ build database queries in raw SQL
--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.
++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.
  == Entities ==
@@ -72,19 +72,19 @@
  === Advanced Entity Inspector ===
--**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.
++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.
--**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.
++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.
--**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.
++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.
--**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.
++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.
--**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.
++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.
--**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.
++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.
--**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.
++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.
  == Attributes ==
@@ -100,14 +100,14 @@
  For example, when you specify Number as the value class for a particular attribute, you are telling Enterprise Objects to use java.lang.Number, which is an abstract class. This is where the value type characteristic steps in. It specifies the exact class an attribute should map to.
  The possible value types for numeric attributes are as follows(note case):
--■ b~-~--java.lang.Byte
--■ s~-~--java.lang.Short
--■ i~-~--java.lang.Integer
--■ l~-~--java.lang.Long
--■ f~-~--java.lang.Float
--■ d~-~--java.lang.Double
--■ B~-~--java.math.BigDecimal
--■ c~-~--java.lang.Boolean
++■ b—java.lang.Byte
++■ s—java.lang.Short
++■ i—java.lang.Integer
++■ l—java.lang.Long
++■ f—java.lang.Float
++■ d—java.lang.Double
++■ B—java.math.BigDecimal
++■ c—java.lang.Boolean
  == Prototypes ==
@@ -120,7 +120,7 @@
  ~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.
 . An entity named EOPrototypes.
--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.
++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.
  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.
@@ -128,13 +128,13 @@
  Every relationship has a cardinality. The cardinality defines how many destination records can potentially resolve the relationship. In relational database systems, there are generally two cardinalities:
--■ to-one relationship~-~--for each source record, there is exactly one corresponding destination record
--■ to-many relationship~-~--for each source record, there may be zero, one, or more corresponding destination
++■ to-one relationship—for each source record, there is exactly one corresponding destination record
++■ to-many relationship—for each source record, there may be zero, one, or more corresponding destination
  records
  An employeeDepartment relationship is an example of a to-one relationship: An employee can be associated with only one department in a company. An Employee entity might also be associated with a Project entity. In this case, there would be a to-many relationship from Employee to Project called projects since an Employee can have many projects.
--The construction of a relationship requires that you designate at least one attribute in each entity as a relationship key.
++The construction of a relationship requires that you designate at least one attribute in each entity as a relationship key.
  There are some general guidelines when choosing which attributes to use as relationship keys. In to-one relationships, the destination key must be a primary key in the destination entity. In to-many relationships, the destination key is usually a foreign key in the destination entity (which is most often a copy of the source entity's primary key). The source key or foreign key should emulate the destination key in that the data types must be the same and the names should be similar.
@@ -154,22 +154,22 @@
  === Flattened Relations ===
--A flattened attribute is a special kind of attribute that you effectively add from one entity to another by traversing a relationship. When you form a to-one relationship between two entities (such as Person and PersonPhoto), you can add attributes from the destination table to the source table. For example, you can add a personPhoto attribute to the Person entity. This is called "flattening" an attribute and is equivalent to creating a joined column~-~--it allows you to create objects that extend across tables.
++A flattened attribute is a special kind of attribute that you effectively add from one entity to another by traversing a relationship. When you form a to-one relationship between two entities (such as Person and PersonPhoto), you can add attributes from the destination table to the source table. For example, you can add a personPhoto attribute to the Person entity. This is called "flattening" an attribute and is equivalent to creating a joined column—it allows you to create objects that extend across tables.
  Flattening attributes is just another way to conceptually "add" an attribute from one entity to another. A generally better approach is to traverse the object graph directly through relationships. Enterprise Objects makes this easy by supporting the notion of key paths.
  The difference between flattening attributes and traversing the object graph (either programmatically or by using key paths) is that the values of flattened attributes are tied to the database rather than the object graph. If an enterprise object in the object graph changes, a flattened attribute can quickly get out of sync.
--For example, suppose you flatten a departmentName attribute into an Employee object. If a user then changes an employee's department reference to a different department or changes the name of the department itself, the flattened attribute won't reflect the change until the changes in the object graph are committed to the database and the data is refetched (this is because flattened attributes are derived attributes~-~--see "Definition (Derived Attributes)" (page 38) for more details). However, if you're using key paths in this scenario, users see changes to data as soon as they happen in the object graph. This ensures that your application's view of the data remains internally consistent.
++For example, suppose you flatten a departmentName attribute into an Employee object. If a user then changes an employee's department reference to a different department or changes the name of the department itself, the flattened attribute won't reflect the change until the changes in the object graph are committed to the database and the data is refetched (this is because flattened attributes are derived attributes—see "Definition (Derived Attributes)" (page 38) for more details). However, if you're using key paths in this scenario, users see changes to data as soon as they happen in the object graph. This ensures that your application's view of the data remains internally consistent.
  Therefore, you should use flattened attributes only in the following cases:
  ■ If you want to combine multiple tables joined by a one-to-one relationship to form a logical unit. For example, you might have employee data that's spread across multiple tables such as ADDRESS, BENEFITS, and so on. If you have no need to access these tables individually (that is, if you'd never need to create an Address object since the address data is always subsumed in the Employee object), then it makes sense to flatten attributes from those entities into the Employee entity.
--■ If your application is read-only.
++■ If your application is read-only.
  ■ If you're using vertical inheritance mapping. See "Vertical Mapping" (page 69).
  === Reflexive Relationships ===
--A unique kind of relationship is the reflexive relationship~-~--a relationship that shares the same source and destination entity. Reflexive relationships are important when modeling data in which an instance of an entity points to another instance of the same entity.
++A unique kind of relationship is the reflexive relationship—a relationship that shares the same source and destination entity. Reflexive relationships are important when modeling data in which an instance of an entity points to another instance of the same entity.
  For example, to show who a given person reports to, you could create a separate manager entity. It would be easier, however, to just create a reflexive relationship. The managerID attribute is the relationship's source key whereas employeeID is the relationship's destination key. Where a person's managerID is the employeeID of another employee object, the first employee reports to the second. If an employee doesn't have a manager, the value for the managerID attribute is null in that employee's record.
@@ -190,10 +190,10 @@
  ==== Delete Rule ====
  The options in the Delete Rule section specify what to do when the source object of a relationship is deleted. There are four options:
--■ **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).
--■ **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.
--■ **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.
--■ **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.
++■ 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).
++■ 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.
++■ 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.
++■ 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.
  === Tips ===
@@ -203,7 +203,7 @@
  Relationships can be compound, meaning that they can consist of multiple pairs of connected attributes. You can specify additional pairs of attributes only in the Relationship Inspector. Simply select a second source attribute and a second destination attribute and click Connect a second time.
--A to-one relationship from one foreign key to a primary key must always have exactly one row in the destination entity~-~--if this isn't guaranteed to be the case, use a to-many relationship. This rule doesn't apply to a foreign key to primary key relationship where a null value for the foreign key in the source row indicates that no row exists in the destination.
++A to-one relationship from one foreign key to a primary key must always have exactly one row in the destination entity—if this isn't guaranteed to be the case, use a to-many relationship. This rule doesn't apply to a foreign key to primary key relationship where a null value for the foreign key in the source row indicates that no row exists in the destination.
  To-one relationships must join on the complete primary key of the destination entity.
@@ -233,12 +233,12 @@
  {{code}}
--EOModelGroup modelGroup = EOModelGroup.defaultGroup();
--EOFetchSpecification fs = modelGroup.fetchSpecificationNamed("MyFetch", "Listing");
++EOModelGroup modelGroup = EOModelGroup.defaultGroup();
++EOFetchSpecification fs = modelGroup.fetchSpecificationNamed("MyFetch", "Listing");
  fs = fs.fetchSpecificationWithQualifierBindings(dictionary);
--NSMutableDictionary dictionary = new NSMutableDictionary();
--dictionary.takeValueForKey("500000", "askingPrice");
--dictionary.takeValueForKey("4", "bedrooms");
++NSMutableDictionary dictionary = new NSMutableDictionary();
++dictionary.takeValueForKey("500000", "askingPrice");
++dictionary.takeValueForKey("4", "bedrooms");
  dictionary.takeValueForKey("3", "bathrooms");
  {{/code}}
@@ -247,11 +247,11 @@
  You can set up an EOModel so that Enterprise Objects automatically invokes a stored procedure for these operations on an entity:
--**Insert** to insert a new object into an entity
--**Delete** to delete an object from an entity
--**Fetch All** to fetch all objects in an entity
--**Fetch w/ PK** to fetch the object in an entity with a particular primary key
--**Get PK** to generate a new primary key for an entity
++Insert to insert a new object into an entity
++Delete to delete an object from an entity
++Fetch All to fetch all objects in an entity
++Fetch w/ PKto fetch the object in an entity with a particular primary key
++Get PK to generate a new primary key for an entity
  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.
@@ -261,25 +261,25 @@
  For each of the operations, if the stored procedure associated with an operation returns a value, Enterprise Objects ignores the return value.
--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.
++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.
  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.
--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.
++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.
--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.
++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.
--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.
++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.
--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.
++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.
--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.
++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.
--**Insert**, **Delete**, and **Get PK** operations should not return a result set.
++Insert, Delete, and Get PK operations should not return a result set.
  == EO Inheritance ==
--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.
++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.
  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.
@@ -321,7 +321,7 @@
  ==== Disadvantages of Horizontal Mapping ====
--Problems may occur when attributes need to be added to the Person superclass. The number of tables that need to be altered is equal to the number of subclasses~-~--the more subclasses you have, the more effort is required to maintain the superclass.
++Problems may occur when attributes need to be added to the Person superclass. The number of tables that need to be altered is equal to the number of subclasses—the more subclasses you have, the more effort is required to maintain the superclass.
  If, for example, you need to add an attribute called middleName to the Person class, you then need to alter its subclasses, Employee and Customer. So if you have deep inheritance hierarchies or many subclasses, this can be tedious. However, if table maintenance happens far less often than fetches, this might be a viable approach for your application.
@@ -340,30 +340,14 @@
  ==== Disadvantages of Single-Table Mapping ====
  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.
++
--=== Using Inheritance in Entity Modeler ===
--
--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).
--
  == EOGenerator ==
--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.
--
--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.//
--
  == Handling Blob Data ==
  == Connection Dictionary ==
--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.
--
--If you wish
--
--#dbConnectUserGLOBAL=
--#dbConnectPasswordGLOBAL=
--dbConnectURLGLOBAL = jdbc:h2:file:,,/politimo
--dbConnectPluginGLOBAL = H2PlugIn,,
--
  == Runtime Selection of the Connection Dictionary and Prototypes ==
  == Debugging JDBC Connections and Jdbc2info ==

Changes for page The EOModel

Summary

Details

Applications

Navigation

My Recent Modifications

Need help?