WWW.BOOK.DISLIB.INFO
FREE ELECTRONIC LIBRARY - Books, dissertations, abstract
 
<< HOME
CONTACTS



Pages:     | 1 |   ...   | 10 | 11 || 13 | 14 |   ...   | 27 |

«Introduction to Core Data Programming Guide 11 Who Should Read This Document 11 Organization of This Document 11 See Also 13 Technology Overview 14 ...»

-- [ Page 12 ] --

The example shows that, because pre-refresh values are applied after awakeFromFetch, you cannot use awakeFromFetch to ensure that a transient value is properly updated following a refresh (or if you do, the value will subsequently be overwritten). In these circumstances, the best solution is to use an additional instance variable to note that a refresh has occurred and that the transient value should be recalculated. For example, 2012-09-19 | Copyright © 2004, 2012 Apple Inc. All Rights Reserved.

Using Managed Objects Ensuring Data Is Up-to-Date in the Person class you could declare an instance variable fullNameIsValid of type BOOL and implement the didTurnIntoFault method to set the value to NO. You then implement a custom accessor for the fullName attribute that checks the value of fullNameIsValid—if it is NO, then the value is recalculated.

2012-09-19 | Copyright © 2004, 2012 Apple Inc. All Rights Reserved.

Object Lifetime Management The life-cycle of the data a managed object represents is largely independent of the lifetime of individual managed object instances. In order to add a record to a persistent store, you must allocate and initialize a managed object—and then save the managed object context. When you remove a record from a persistent store, you should ensure its corresponding managed object is eventually deallocated. In between these events, however, you can create and destroy any number of instances of a managed object that represent the same record in a given persistent store.

The Role of the Managed Object Context Managed objects know what managed object context they’re associated with, and managed object contexts know what managed objects they contain. By default, though, the references between a managed object and its context are weak. This means that in general you cannot rely on a context to ensure the longevity of a managed object instance, and you cannot rely on the existence of a managed object to ensure the longevity of a context. Put another way, just because you fetched an object doesn’t mean it will stay around.

The exception to this rule is that a managed object context maintains a strong reference to any changed (inserted, deleted, and updated) objects until the pending transaction is committed (with a save:) or discarded (with a reset or rollback). Note that the undo manager may also keep strong references to changed objects—see “Change and Undo Management” (page 80).

You can change a context’s default behavior such that it does keep strong references to its managed objects by sending it a setRetainsRegisteredObjects: message (with the argument YES)—this makes the managed objects’ lifetimes depend on the context’s. This can be a convenience if you are caching smaller data sets in memory—for example if the context controls a temporary set of objects that may persist beyond a single event cycle, such as when editing in a sheet. It can also be useful if you are using multiple threads and passing data between them—for example if you are performing a background fetch and passing object IDs to the main thread. The background thread needs to keep strong references to the objects it pre-fetched for the main thread until it knows the main thread has actually used the object IDs to fault local instances into itself.

You should typically use a separate container to keep strong references only those managed objects you really need. You can use an array or dictionary, or an object controller (for example an NSArrayController instance) that has strong references the objects it manages. The managed objects you don’t need will then be deallocated when possible (for example, when relationships are cleared).

2012-09-19 | Copyright © 2004, 2012 Apple Inc. All Rights Reserved.

Object Lifetime Management Breaking Relationship Strong Reference Cycles If you have finished with a managed object context, or for some other reason you want to “disconnect” a

context from its persistent store coordinator, you should not set the context’s coordinator to nil:

// This will raise an exception.

[myManagedObjectContext setPersistentStoreCoordinator:nil];

Instead, you should simply relinquish ownership of the context and allow it to be deallocated normally.

Breaking Relationship Strong Reference Cycles When you have relationships between managed objects, each object maintains a strong reference to the object or objects to which it is related. This can cause strong reference cycles. To ensure that reference cycles are broken, when you're finished with an object you can use the managed object context method refreshObject:mergeChanges: to turn it into a fault.

You typically use refreshObject:mergeChanges: to refresh a managed object’s property values. If the mergeChanges flag is YES, the method merges the object’s property values with those of the object available in the persistent store coordinator. If the flag is NO, however, the method simply turns an object back into a fault without merging, which causes it to break strong references to related managed objects. This breaks the strong reference cycle between that managed object and the other managed objects.

Note that, of course, before a managed object can be deallocated there must be no strong references to it, including from outside of Core Data. See also “Change and Undo Management” (page 80).





Change and Undo Management A context keeps strong references to managed objects that have pending changes (insertions, deletions, or updates) until the context is sent a save:, reset, rollback, or dealloc message, or the appropriate number of undos to undo the change.

The undo manager associated with a context keeps strong references to any changed managed objects. By default, in OS X the context’s undo manager keeps an unlimited undo/redo stack. To limit your application's memory footprint, you should make sure that you scrub (using removeAllActions) the context’s undo stack as and when appropriate. Unless you keep a strong reference to a context’s undo manager, it is deallocated with its context.

2012-09-19 | Copyright © 2004, 2012 Apple Inc. All Rights Reserved.

Object Lifetime Management Change and Undo Management If you do not intend to use Core Data’s undo functionality, you can reduce your application's resource requirements by setting the context’s undo manager to nil. This may be especially beneficial for background worker threads, as well as for large import or batch operations.

2012-09-19 | Copyright © 2004, 2012 Apple Inc. All Rights Reserved.

Relationships and Fetched Properties There are a number of things you have to decide when you create a relationship. What is the destination entity?

Is it a to-one or a to-many? Is it optional? If it’s a to-many, are there maximum or minimum numbers of objects that can be in the relationship? What should happen when the source object is deleted? You can provide answers to all these in the model. One of the particularly interesting cases is a many-to-many relationship;

there are two ways to model these, and which one you choose will depend on the semantics of your schema.

When you modify an object graph, it is important to maintain referential integrity. Core Data makes it easy for you to alter relationships between managed objects without causing referential integrity errors. Much of this behavior derives from the relationship descriptions specified in the managed object model.

Core Data does not let you create relationships that cross stores. If you need to create a relationship from objects in one store to objects in another, you should consider using fetched properties.

Relationship Definitions in the Model Creating a relationship in a managed object model is straightforward, but there are a number of aspects of a relationship that you need to specify properly. The most immediately obvious features are the relationship's name, the destination entity, and the cardinality (is it a to-one relationship, or a to-many relationship). The most important features with respect to object graph integrity, however, are the inverse relationship and the delete rule. The validity of the graph is affected by the settings for optionality and for maximum and minimum count.

Relationship Fundamentals A relationship specifies the entity, or the parent entity, of the objects at the destination. This can be the same as the entity at the source (a reflexive relationship). Relationships do not have to be homogeneous. If the Employee entity has two sub-entities, say Manager and Flunky, then a given department's employees may be made up of Employees (assuming Employee is not an abstract entity), Managers, Flunkies, or any combination thereof.

You can specify a relationship as being to-one or to-many. To-one relationships are represented by a reference to the destination object. To-many relationships are represented by mutable sets (although fetched properties are represented by arrays). Implicitly, “to-one” and “to-many” typically refer to “one-to-one” and “one-to-many” 2012-09-19 | Copyright © 2004, 2012 Apple Inc. All Rights Reserved.

Relationships and Fetched Properties Relationship Definitions in the Model relationships respectively. A many-to-many relationship is one where a relationship and its inverse are both to-many. These present some additional considerations, and are discussed in greater detail in “Many-to-Many Relationships” (page 86).

You can also put upper and lower limits on the number of objects at the destination of a to-many relationship.

The lower limit does not have to be zero. You can if you want specify that the number of employees in a department must lie between 3 and 40. You also specify a relationship as either optional or not optional. If a relationship is not optional, then in order to be valid there must be an object or objects at the destination of the relationship.

Cardinality and optionality are orthogonal properties of a relationship. You can specify that a relationship is optional, even if you have specified upper and/or lower bounds. This means that there do not have to be any objects at the destination, but if there are then the number of objects must lie within the bounds specified.

It is important to note that simply defining a relationship does not cause a destination object to be created when a new source object is created. In this respect, defining a relationship is akin to declaring an instance variable in a standard Objective-C class. Consider the following example.

@interface Widget : NSObject {

–  –  –

} If you create an instance of Widget, an instance of Sprocket is not created unless you write code to cause it to happen (for example, by overriding the init method). Similarly, if you define an Address entity, and a non-optional to-one relationship from Employee to Address, then simply creating an instance of Employee does not create a new Address instance. Likewise, if you define a non-optional to-many relationship from Employee to Address with a minimum count of 1, then simply creating an instance of Employee does not create a new Address instance.

Inverse Relationships Most relationships are inherently bi-directional. If a Department has a to-many relationship to the Employees that work in a Department, there is an inverse relationship from an Employee to the Department. The major exception is a fetched property, which represents a weak one-way relationship—there is no relationship from the destination to the source (see “Fetched Properties” (page 89)).

2012-09-19 | Copyright © 2004, 2012 Apple Inc. All Rights Reserved.

Relationships and Fetched Properties Relationship Definitions in the Model You should typically model relationships in both directions, and specify the inverse relationships appropriately.

Core Data uses this information to ensure the consistency of the object graph if a change is made (see “Manipulating Relationships and Object Graph Integrity” (page 85)). For a discussion of some of the reasons why you might not want to model a relationship in both directions, and some of the problems that might arise if you don’t, see “Unidirectional Relationships” (page 88).

Relationship Delete Rules A relationship's delete rule specifies what should happen if an attempt is made to delete the source object.

Note the phrasing in the previous sentence—"if an attempt is made…". If a relationship's delete rule is set to Deny, it is possible that the source object will not be deleted. Consider again a department's employees relationship, and the effect that the different delete rules have.



Pages:     | 1 |   ...   | 10 | 11 || 13 | 14 |   ...   | 27 |


Similar works:

«Univerzita Karlova v Praze Matematicko-fyzik´ln´ fakulta aı ´ ´ DIPLOMOVA PRACE Zdenˇk Sibl´ e ık Compressing Proxy Katedra softwarov´ho inˇen´rstv´ e zy ı Vedouc´ diplomov´ pr´ce: RNDr. V´clav Petˇ´cek ı ea a rıˇ Studijn´ program: INFORMATIKA, Softwarov´ syst´my ı e e ii Dˇkuji pˇedevˇ´ vedouc´ e r sım ımu sv´ diplomov´ pr´ce V´clavu Petˇ´ckovi za trpˇlivost, odborn´ e ea a rıˇ e e rady a cenn´ pˇipom´ er ınky, kter´ mi velice pomohly pˇi...»

«Im Bann Der Nacht Guardians Of Eternity 4 Roman Guardians Of Eternity Serie Band 4 Der Auto sei davor Im Bann der Nacht: Guardians of Eternity 4 Roman (Guardians of EternitySerie, Band 4) wec und die Gemeinschaft ist es, der MOMENTEN. Am Turniers sollte auf den Bretter das Film der Euro in diesem Wind Mitte dieser Flamme auf Merkel fressenakzeptabel werden. Von der Betreuerin die rasche online Quick-Settings schauen Alex dank der politische Mann aus der Graduiertenschulen Landes ahnte die...»

«Composing for Japanese Instruments Adrian Freedman 1 CONTENTS Preface Introduction Instruments Shakuhachi Koto Starting Points for Composition Timbre and Texture Melody Heterophony Rhythm Notation Japanese Scales Styles of Japanese Music Ma – sound and silence 2 PREFACE These notes were written as a resource for the AUDIOWORKS project in Cornwall, 2005. The project was organised by Derek Kitt, Music Advisor for Cornwall, and was funded by the National Foundation for Youth Music and supported...»

«Barbara Pieper Subjektorientierung jenseits des Zaunes: Anregungen für die Praxis Ideen aus der Praxis ® (Feldenkrais-Methode ) Alle Menschen streben von Natur nach Wissen. Dies zeigt ihre Liebe zu den Sinneswahrnehmungen. Aristoteles Zusammenfassung: Zunächst veranschauliche ich, wie mir die subjektorientierte Perspektive in der Soziologie in meiner neuen Tätigkeit als Feldenkrais-Pädagogin wiederbegegnet ist. Ich wähle hierzu das Lernkonzept der Feldenkrais-Methode (organic learning)....»

«A Cooperação Sul-Sul e Triangular na CPLP : boas práticas na proteção social e no combate ao trabalho infantil A Cooperação Sul-Sul e Triangular na CPLP: Boas práticas na proteção social e no combate ao trabalho infantil A Cooperação Sul-Sul e Triangular na CPLP: Boas práticas na proteção social e no combate ao trabalho infantil Coordenação: Anita Amorim, Pedro Américo de Oliveira, Nuno Tavares Martins Autores: Anita Amorim, Beatriz Caetano Pinto, Fabio Durán Valverde, Helmut...»

«The Role of Oxygen in the Aging of Bottled Wine Allen Hart1, Andrew Kleinig 1,2. Southcorp Wines Pty Ltd, Moyston Road, Great Western, Vic 3377; 2 1,2 current address; Tarac Technologies, PO Box 78 Nuriootpa SA 5355 Abstract. There are many factors, which are important in the evolution of wines during aging in bottle. Whilst it is accepted that the interaction of limited amounts of oxygen with bottled wine (via closure ingress) will not benefit white wine, it is widely held that limited amounts...»

«Dissertation submitted to the Combined faculties for the natural Sciences and for Mathematics of the Ruperto-Carola University of Heidelberg, Germany for the degree of Doctor of Natural Sciences Put forward by Dipl.-Phys. Uroš Kržič Born in Slovenj Gradec, Slovenia Oral examination: 8th July 2009 Multiple-view microscopy with light-sheet based fluorescence microscope Referees: Prof. Dr. Jörg Schmiedmayer, Vienna University of Technology Prof. Dr. Bernd Jähne, Heidelberg University...»

«L 11 AS 105/10 B PKH S 35 AS 255/10 ER SG Kiel SCHLESWIG-HOLSTEINISCHES LANDESSOZIALGERICHT BESCHLUSS In dem Beschwerdeverfahren die Antragsteller zu 3) und 4) vertreten durch ihre Mutter, die Antragstellerin zu 1) Antragsteller und Beschwerdeführer Prozessbevollmächtigter: gegen jobcenter.kiel, Arbeitsgemeinschaft für Arbeit und Integration, Adolf-Westphal-Straße 2, 24143 Kiel, Antragsgegner und Beschwerdegegner hat der 11. Senat des Schleswig-Holsteinischen Landessozialgerichts am 4....»

«Adaptive Modellierung und Simulation Rüdiger Brause Speicher 4 2.3 2.2 2.1 FB Informatik und Mathematik Institut für Informatik Rüdiger Brause Adaptive Modellierung und Simulation Grundlagen und Konzepte Skript zur Vorlesung SS 2015 © R.Brause, Goethe-Universität 2015 Prof. Dr. Rüdiger Brause Adaptive Systemarchitektur Institut für Informatik J. W. Goethe-Universität Frankfurt am Main 60054 Frankfurt Email: R_Brause@informatik.uni-frankfurt.de Home:...»

«INDIVIDUAL AND POLITY IN THE VITA OF FRANCESCO SANSOVINO FRANCESCO SANSOVINO, “Al Magnifico Signor Gian Filippo Magnanini Secretario dell’Illustrissimo Signor Cornelio Bentivoglio (.) Di Venetia, alli 15. di Dicembre 1579”, in: FRANCESCO SANSOVINO: Del Secretario Libri VII (Venezia 1584), fols. 219 recto-222 recto. edited by CHARLES DAVIS FONTES 45 [25. January 2010] Zitierfähige URL: http://archiv.ub.uni-heidelberg.de/artdok/volltexte/2010/892/ urn:nbn:de:bsz:16-artDok-8929 DEL...»





 
<<  HOME   |    CONTACTS
2016 www.book.dislib.info - Free e-library - Books, dissertations, abstract

Materials of this site are available for review, all rights belong to their respective owners.
If you do not agree with the fact that your material is placed on this site, please, email us, we will within 1-2 business days delete him.