Some things to avoid when working with EOF. Some of these things are contraindicated in Apple documentation, others are not. But all are things that experience shows EOF does not expect, and can lead to all sorts of trouble, including mysterious exceptions, and EOF getting confused about what changes must be saved to the database.

1. Don't set EO properties in the EO constructor - use awakeFromInsertion(...) or awakeFromFetch(...) instead.
2. Don't do anything to an EO before inserting it into an editing context. Always insert EOs into ECs immediately. See rule #1.
3. Don't modify any EO properties in validateFor...(...) methods. Doing this in validateValueForKey(...) is ok as [Chuck Hill] noted in the list.
4. If overriding awakeFromInsertion(...), remember to call ther superclass implementation. Same with awakeFromFetch(...).
5. Don't change the behavior of methods that EOF uses. For example, do not override to-many relationships to return a sorted list of the related objects. Make another method to do this.
6. Don't use EOF in model class static initializers. Doing so forces EOF into operational mode before the frameworks are initialized. Use lazy loading of the entity instead.
7. Don't use mutable classes (NSMutableArray, NSMutableDictionary, or any other class that can change internal state after creation) as attributes. If you want this effect, use immutable classes and provide cover methods to replace the immutable instance with an updated instance. You and EOF will be much, much, much happier. For example:

   public void addAppointment(String time, String reason) {
       super.willChange();
       NSMutableDictionary mutableAppointments = appointments().mutableClone();
       mutableAppointments.setObjectForKey(reason, time);
       setAppointments(mutableAppointments.immutableClone());
   }