[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The model related classes are important in that they define a databases structure. Giving GDL2 a way to map a relational database into a set of objects.
4.4 EOModel class | EOModel | |
4.5 EOEntity class | EOEntity | |
4.6 EOAttribute class | EOAttribute | |
4.7 EORelationship class | EORelationship | |
4.8 EOModelGroup class | EOModelGroup |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The database specific classes loadable through bundles provide a method for GDL2 to connect to and abstract implementation details between different database implementations.
Currently adaptors for SQLite3 and PostgreSQL exist.
4.9 EOAdaptor class | EOAdaptor | |
4.11 EOAdaptorChannel class | EOAdaptorChannel | |
4.10 EOAdaptorContext class | EOAdaptorContext |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The data oriented classes relate to actual data manipulation and management.
4.12 EODataSource class | EODataSource | |
4.13 EOEditingContext class | EOEditingContext | |
4.14 EOGenericRecord class | EOGenericRecord |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A model represents GDL2s interface to a database. It contains information required to connect to the database along with entities and stored procedures.
All the model classes can be written to and read from property list files in the form of .eomodel or .eomodeld files. While .eomodel files contain a model and all its entities and objects in a single property list, .eomodeld files are a directory with each of the property lists in their own file.
Typically you won’t create an model through manual instantiation of the classes but store them in and read them from a property list. We have provided an example .eomodel file See section Example model file.
An EOModel Typically has:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An entity contains information pertaining to a table in a database in the form of attributes and relationships.
Additionally an entity contains:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A class property of an entity can be either an attribute or a relationship. typically class properties are the set of attributes or relationships which are user visible and need to be set or accessed by the user. Primary and Foreign keys attributes are usually derived from other attributes or generated automatically and so they are not typically class properties.
A class property will be available through Key Value Coding for access and modification, in an instance of an Enterprise object.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
an EOEntity’s class name represents the name of the class which will be instantiated when creating an Enterprise Object such as EOGenericRecord or a custom object.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Primary key attributes specify which attributes uniquely identify a row in the table, they are typically generated automatically by GDL2. They correspond directly to the relational database concept.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The external name represents the table name in the database server, and in any SQL the adaptor might generate.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An attribute typically maps a table column to an instance variable, in which case the attribute is a class property. Some attributes represent foreign keys which are used to create realationships yet do not correspond to a property in the enterprise object. Other attributes may represent primary keys which needn’t be class property either. In fact some parts of framework work more smoothly if primary key attributes and foreign key attributes are not class properties.
Attributes typically contain:
Some additional properties an attribute may have:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The attributes name when the attribute is a class property is used as the key when doing key value coding on an enterprise object.
It also uniquely identifies the attribute in its entity there many not be an attribute with the same name as another attribute or relationship in an entity.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The adaptor uses the column name in generating SQL.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Indicates the type of the attribute as contained in the database
Valid adaptor value types are:
Corresponding to numerical, string, raw data, and date value types.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An external type is a string representing an adaptor specific database type different adaptors may use different names where the PostgreSQL adaptor might use ’char’. The SQLite3 Adaptor might use ’TEXT’
it gives you full control on how the data is stored in the specific adaptor where the adaptor value type allows you to specify a few generic values.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Value types are a string with a single character such as ’f’ for floats ’c’ for chars a full list of the standard types is available in the GDL2 API reference for EOAttributes -valueType method.
The value type allows you to further refine the adaptor value type where EOAdaptorNumberType might represent a integer, float, or double type.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The value class name specifies the class which will be present in an Enterprise Object containing the attribute.
A property of this class will be instantiated when a field is retrieved from the database, similarly a instance of this will be converted into the external type when being sent to the datbase server.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When the Value Class Name is a custom object for instance NSImage created from a blob of data. The value factory method name denotes the initializer for the class, used to create a new instance of the custom class.
The value class name is an NSString representing a selector accepting a single argument suitable for passing to the NSSelectorFromString function.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This is the type of the argument sent to the value factory method name.
Valid types are
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A relationship represents a connecton between entities and are described with EOJoin’s. A join defines source and destination attributes – The attributes of the joining entity which must match.
A relationship may be of type to-one or to-many. In a to-many the destination will be an array of objects, and a to-one relationships destination a single object.
Typically a relationship is a class property. Yet some relationships may soley be used for flattening other relationships which are class properties, yet need not be class properties themselves.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When models have relationships to other models, they ask their model group.
There is a special model group - the default model group - which contains all the models in the applications resources and the resources of any frameworks the application uses. If your model file is not available through application or framework resources you will need to add it to a model group.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An adaptor abstracts the difference between different database implementations. It can connect to the database with the help of a connection dictionary and create and execute SQL statements.
While an adaptor is made up of many different classes. The EOAdaptor class is sort of an entry point into the different available classes.
And a typical use for the EOAdaptor class is creating an instance of a specific adaptor, either by name or through the adaptor name in a model.
Typical methods for the EOAdaptor class are:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An EOAdaptorContext can create an adaptor channel and will transparently handle transactions for the channel, It can begin, commit, roll back transactions.
Additionaly you can enable debugging on the context and its channels.
Typical methods for an EOAdaptorContext:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An adaptor channel can open and close a connection to the adaptors database server. Along with fetch rows from the database and create, update, and delete rows in the database.
It is the main communication channel for gdl2, in creating the connection to the database, and executing any SQL statements which have been prepared through EOSQLExpression. Though it also has methods for building SQL expressions from entities, and possibly turning the results back into enterprise objects.
Because EOAdaptorChannel can create most SQL statements for you, you’ll rarely need to do that yourself, though it is available if needed.
Typical methods for an EOAdaptorChannel:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
EODataSource is an abstract base class, and implements no real functionality on its own, instead you’ll access EODataSource subclass.
A data source represents a collection of rows inside of a table. It can create rows, delete and provide access to the individual rows represented as Enterprise objects.
Typical methods for an EODataSource subclass:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The -fetchObjects method will return an array of enterprise objects. Typically these will be retrieved directly from data in the database server. Then the caller will save the array for access or modification.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The -createObject: method will create a new enterprise object for insertion into the database. A subclass will generally insert this new object into an editing context. Though the caller is responsible for inserting the object into the data source with -insertObject:.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The -insertObject: method will schedule the object for addition into the database server EditingContexts changes are saved to the database.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The -deleteObject: method will schedule the object for removal from the database server when the EOEditingContexts changes are saved to the database.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Subclasses may implement this method to return a detail data source.
A detail data source is a datasource which is created from following a relationship in an object of the receiever: the master object.
in our example you might have a data source for the authors entity and qualify a detail data source, with the toBooks key.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
EODatabaseDataSource class is a subclass of EODataSource.
To initialize an EODatabaseDataSource you’ll give it a reference to an EOEditingContext and an entity name.
EODatabaseDataSource initializers:
Once initialized, you can call the EODataSource methods on it, to create fetch insert, and delete objects from the datasource.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An editing context is responsible for managing changes to enterprise objects and provides the ability to save and undo those changes. Including inserts, updates, and deletes.
Typical methods of the EOEditingContext class:
You may have noticed that there is no mention of a method for modifying an object through an EOEditingContext. As you will modify the objects directly, and EOEditingContext will merely take note of the changes, and save snapshots of the objects as they are being modified so you can undo those changes.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
EOGeneric record represents an actual row in a table being the default enterprise object it contains no custom business logic and is accessible solely through key value coding.
Where an entity represents the description of the table. It’s columns and types. enterprise objects represent the data contained in the table.
EOGenericRecords are generally created with a reference to an entity. They export as keys the class properties of the entity, for access and modification.
If you have an EOGenericRecord from the ’authors’ entity of our example model you could set the authors name as so. See section Example model file.
[anAuthor takeValue:@"Anonymous" forKey:@"name"]; |
And retrieve the author name with:
[anAuthor valueForKey:@"name"]; |
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by root on May 20, 2013 using texi2html 1.82.