WebObjects/EOF/Using EOF/Problems

Problems
This section describes some problems and bugs that sometimes occur when using Enterprise Objects Framework.

EOF fails to initialize models when not specifically ordered

 * Authors: Francis Labrie
 * Affected products: WebObjects 5.2.x, 5.3.x
 * Bug reference: rdar://4571773

Problem:
Sometimes when having several data models using shared objects in a WebObjects application, models load, initialization and connection simply fail with strange and unexpected exceptions. Typical exceptions are:


 * 


 *   


 * etc.

I saw several report of this bug in various mailing list, but no one leads to a right solution or a good explanation:


 * http://lists.apple.com/archives/webobjects-dev/2005/Aug/msg00295.html
 * http://www.wodeveloper.com/omniLists/webobjects-dev/2004/September/msg00255.html

Solution:
I've finally found that this problem is related to the models load and initialization order. Most of the time, EOF is able to initialize a group of models flawlessly. But in some circumstances, it just fails.

The best fix would be to make EOF dynamically analyse models groups, building a graph of dependancy with all entities for each group and ordering the models and the entities initializations according to this graph. But a such solution is a little bit more complex and should typically be integrated directly into the EOAccess layer.

To work around this bug with a simpler solution, you can add in the  dictionary of each model the   key assigned to a value of four digit, example: ,  ,  , etc. You must use priority values with the same number of digit, because these will be converted to strings, and if you set a priority of  , the string value will be considered as higher than a priority of.

Then create a static method that perform an  with each model of the group sorted by priority:

private static final NSArray _PriorityDescendingModelSortOrdering = new NSArray(new Object[] {		EOSortOrdering.sortOrderingWithKey("userInfo.priority", EOSortOrdering.CompareDescending), 		EOSortOrdering.sortOrderingWithKey("name", EOSortOrdering.CompareAscending)	});

...

public static void assertModelGroupConnectionDictionariesAreValid(EOEditingContext editingContext, EOModelGroup modelGroup) { Enumeration models; EOAdaptor adaptor; EODatabaseContext databaseContext; EOModel model;

// Get models enumerator from default group models = EOSortOrdering.sortedArrayUsingKeyOrderArray(modelGroup.models, 			_PriorityDescendingModelSortOrdering).objectEnumerator;

while(models.hasMoreElements) { model = (EOModel)models.nextElement; NSLog.debug.appendln(" Connecting " + model.name + " model, userInfo = " + model.userInfo + "..."); databaseContext = EODatabaseContext.registeredDatabaseContextForModel(model, editingContext); adaptor = databaseContext.adaptorContext.adaptor;

// Test connection dictionary adaptor.assertConnectionDictionaryIsValid; NSLog.debug.appendln(" The \"" + model.name + "\" model is connected."); } // while } // assertConnectionDictionariesAreValid

The sort ordering here sort by descending model priority and ascending model name to ensure constancy on sort result.

You'll have to find the right model order: you can deduce it with logic drawing a dependency graph, or you can find it with tests and errors. Typically, when an exception has above is thrown, it's because the model initialization was done too late. I usually set priority to framework models from  (low) to   (high), and application models from   (low) to   (high).

Exception:
For some cases, this solution still does't help (see this message). I suspect the entities ordering in model to be the problem (see below). If it's still not the case, you can try to use the ERXSharedEOLoader class in Project Wonder.

EOF fails to fetch or save entities when not correctly ordered in model

 * Authors: Francis Labrie
 * Affected products: WebObjects 5.2.x, 5.3.x
 * Bug reference:

Problem:
Sometimes when using inheritance with entities in a data model in a WebObjects application, fetching or saving data may simply fails with strange and unexpected exceptions. Typical exception is:


 *   


 * etc.

Solution:
Typically, this kind of error occurs when the parent entity is in an another model which was initialized after the current entity model one (see above) or when the parent entity is coming after the current entity in the alphabetically ordered list of entities of the current model. To illustrate the latter case: if your abstract parent entity name is "Flower" and you are fetching the concrete sub-entity "Anemone" while both entities are part of the same model, you can get this kind of exception on the first "Anemone" fetch.

To avoid this exception, simply edit the "index.eomodeld" file in a text editor and reorder the entities references in the array, putting parent entities above sub-entities. But you should then take care with the EOModeler: you'll have to reorder these entities references each time you modify and save the model.

New sub-entity insertion fails because primary key is null

 * Authors: initially reported by Chuck Hill
 * Affected products: WebObjects 5.2.x, 5.3.x
 * Bug reference:

Problem:
When a sub-entity have a parent entity with a relationship set to propagate primary key, any new sub-entity insertion when saving changes from an editing context will throw an integrity violation exception because the primary key column is set to.

Solution:
To avoid this bug, uncheck the Propagate primary key relationship property of the parent entity. Unfortunately, if the parent entity is not abstract, this solution will not be applicable: you'll probably have to modify the relationship modeling itself.