EOF-Using EOF-Breaking EOF

Version 16.1 by Ray Kiddy on 2011/10/03 01:26
Warning: For security reasons, the document is displayed in restricted mode as it is not the current version. There may be differences and errors due to this.

You may be seeing problems like these in your application:

I've run into a rather nasty little problem after making some changes to my app recently. The problem never showed in testing and is difficult to contrive (which is the nasty bit). After an arbitrary and large number of requests, an arbitrary and small proportion of fetches fail. That is to say that some fetches give an object whose properties are all null. For example I wish to fetch a Member with username 'x'. I use a named EOFetchSpecification, specify the qualifier bindings and fetch my EOs.


EOFetchSpecification fetchSpec = EOFetchSpecification.fetchSpecificationNamed("usernameFetchSpec", "Member");
fetchSpec = fetchSpec.fetchSpecificationWithQualifierBindings(new NSDictionary("x", "usernameValue"));
NSArray results = ec.objectsWithFetchSpecification(fetchSpec);

In most cases I receive the expected results, but in some the first Member object in the NSArray has a null username, password, etc.

Unknown macro: noformat. Click on this message for details.
 

Unknown macro: noformat. Click on this message for details.

The exception is correct, the snapshot _dbSnapshot = {}; does not contain any values, let alone the one it is looking for. I am not completely sure of how this happens. It is not consistent .

If you want to know the cause of these, go look in a mirror! EOF is not broken, you are abusing it and it is fighting back. Here is what to check:

(wikidiscard -> This information seems too specific and provides no context. I cannot think how looking in a mirror would be helpful. If someone finds this page because they are having a problem, what do they learn from this page? I think that they learn nothing. If there is a point to be made, it can be added to the information in the 'EOF Commandments' page or in some other more appropriate place. -rrk 2011/10/02.)