PATH |
Describes how to get the adaptor, adaptor context, and adaptor channel objects used by an editing context or a display group.
To access an EOEditingContext's adaptor sublayer objects, you get the editing context's EOObjectStoreCoordinator from the editing context, you get an EODatabaseContext from the object store coordinator, and you get the adaptor sublayer objects from there. The following code demonstrates the process.
EOEditingContext editingContext; // Assume this exists. String entityName; // Assume this exists. EOAdaptor adaptor; EOAdaptorContext adContext; EOAdaptorChannel adChannel; EOFetchSpecification fspec = new EOFetchSpecification(entityName, null, null); EOObjectStoreCoordinator rootStore = (EOObjectStoreCoordinator)editingContext.rootObjectStore(); EODatabaseContext dbContext = (EODatabaseContext)rootStore. objectStoreForFetchSpecification(fspec); EODatabaseChannel dbChannel = dbContext.availableChannel(); adaptor = dbContext.database().adaptor(); adContext = dbContext.adaptorContext(); adChannel = dbChannel.adaptorChannel(); adChannel.openChannel(); // before you use the database // channel or the adaptor channel
This example first creates a fetch specification, providing just the entity name as an argument. Of course, you can use a fetch specification that has non- null values for all of its arguments, but only the entity name is used by the EOObjectStore objectStoreForFetchSpecification method. Next, the example gets the editing context's EOObjectStoreCoordinator using the EOEditingContext method rootObjectStore . This method returns an EOObjectStore and not an EOObjectStoreCoordinator, because it's possible to substitute a custom object store in place of an object store coordinator. Similarly, the EOObjectStoreCoordinator method objectStoreForFetchSpecification returns an EOCooperatingObjectStore instead of an EODatabaseContext because it's possible to substitute a custom cooperating object store in place of a database context. If your code performs any such substitutions, you should alter the above code example to match your custom object store's API. See the class specifications for EOObjectStore, EOObjectStoreCoordinator, and EOCooperatingObjectStore for more information.
The EODatabaseContext maintains a link to its EOAdaptorContext from which the code gets the EOAdaptor. To get the EOAdaptorChannel, the code invokes availableChannel on the EODatabaseContext, which creates an EODatabaseChannel and an EOAdaptorChannel if they don't already exist.
An EOEditingContext's EOObjectStoreCoordinator can have more than one set of database and adaptor sublayer objects. Consequently, to get a database context from the object store coordinator, you have to provide information that the coordinator can use to choose the correct database context. The code example above provides an EOFetchSpecification using the method objectStoreForFetchSpecification , but you could specify different criteria by using one of the following EOObjectStoreCoordinator methods instead:
After you have the database context, you can get the corresponding EOAdaptor and EOAdaptorContext as shown in the example above.
If you are using a display group and a corresponding EODatabaseDataSource, the code to access the adaptor layer objects is a little simpler.
WODisplayGroup myDisplayGroup; // Assume exists EOAdaptorContext myAdaptorContext; EOAdaptor myAdaptor; EODatabaseDataSource ds = (EODatabaseDataSource)myDisplayGroup.dataSource(); EODatabaseContext dbContext = ds.databaseContext(); EODatabaseChannel dbChannel = dbContext.availableChannel(); myAdaptorContext = dbContext().adaptorContext(); myAdaptor = myAdaptorContext.adaptor(); myAdaptorChannel = dbChannel.adaptorChannel();
The code first gets the display group's EODatabaseDataSource. From there it finds the display group's EODatabaseContext.