FREE ELECTRONIC LIBRARY - Books, dissertations, abstract

Pages:     | 1 |   ...   | 17 | 18 || 20 | 21 |   ...   | 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 19 ] --

The default behavior is defined by the NSErrorMergePolicy. This policy causes a save to fail if there are any merge conflicts. In the case of failure, the save method returns with an error with a userInfo dictionary that contains the key @"conflictList"; the corresponding value is an array of conflict records. You can use the array to tell the user what differences there are between the values they are trying to save and those current in the store. Before you can save you must either fix the conflicts (by re-fetching objects so that the snapshots are updated) or choose a different policy. The NSErrorMergePolicy is the only policy that generates an error. Other policies—NSMergeByPropertyStoreTrumpMergePolicy, NSMergeByPropertyObjectTrumpMergePolicy, and NSOverwriteMergePolicy—allow the save to proceed by merging the state of the edited objects with the state of the objects in the store in different ways.

The NSRollbackMergePolicy discards in-memory state changes for objects in conflict and uses the persistent store’s version of the objects’ state.

Snapshot Management An application that fetches hundreds of rows of data can build up a large cache of snapshots. Theoretically, if enough fetches are performed, a Core Data-based application can contain all the contents of a store in memory.

Clearly, snapshots must be managed in order to prevent this situation.

Responsibility for cleaning up snapshots rests with a mechanism called snapshot reference counting. This mechanism keeps track of the managed objects that are associated with a particular snapshot—that is, managed objects that contain data from a particular snapshot. When there are no remaining managed object instances associated with a particular snapshot (which Core Data determines by maintaining a list of these references), the strong reference to the snapshot is broken.

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

Change Management Communicating Changes Between Contexts Communicating Changes Between Contexts If you use more than one managed object context in an application, Core Data does not automatically notify one context of changes made to objects in another. In general, this is because a context is intended to provide a scratch pad where you can make changes to objects in isolation, and if you wish you can discard the changes without affecting other contexts. If you do need to synchronize changes between contexts, how a change should be handled depends on the user visible semantics you want in the second context, and on the state of the objects in the second context.

Consider an application with two managed object contexts and a single persistent store coordinator. If a user deletes an object in the first context (moc1), you may need to inform the second context (moc2) that has been deleted. In all cases, moc1 posts an NSManagedObjectContextDidSave notification that your application should register for and use as the trigger for whatever actions it needs to take. This notification contains information not only about deleted objects, but also about changed objects. You need to handle these changes since they may be the result of the delete (most of the ways this can happen involve transient relationships or fetched properties).

There are multiple axes you must consider when deciding how you want to handle your delete notification.

The important ones are:

What other changes exist in the second context?

● Does the instance of the object that was deleted have changes in the second context?

● Can the changes made in the second context be undone?

● These are somewhat orthogonal, and what actions you take to synchronize the contexts depend on the semantics of your application. The following three strategies are presented in order of increasing complexity.

1. The simplest case is when the object itself has not changed in moc2 and you do not have to worry about undo; in this situation, you can just delete the object. The next time moc2 saves, the framework will notice that you are trying to re-delete an object, ignore the optimistic locking warning, and continue without error.

2. If you do not care about the contents of moc2, you can simply reset it (using reset) and refetch any data you need after the reset. This will reset the undo stack as well, and the deleted object is now gone. The only issue here is determining what data to refetch. You can do this by, before you reset, collecting the IDs (objectID) of the managed objects you still need and using those to reload once the reset has happened (you must exclude the deleted IDs, and it is best to create fetch requests with IN predicates to avoid problems will not being able to fulfill faults for deleted IDs).

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

Change Management Communicating Changes Between Contexts

3. If the object has changed in moc2, but you do not care about undo, your strategy depends on what it means for the semantics of your application. If the object that was deleted in moc1 has changes in moc2, should it be deleted from moc2 as well? Or should it be resurrected and the changes saved? What happens if the original deletion triggered a cascade delete for objects that have not been faulted into moc2? What if the object was deleted as part of a cascade delete?

There are two workable options (a third, unsatisfactory option is described later):

a. The simplest strategy is to just discard the changes by deleting the object.

b. Alternatively, if the object is standalone, you can set the merge policy on the context to NSMergePolicyOverwrite. This will cause the changes in the second context to overwrite the delete in the database.

Note that this will cause all changes in moc2 to overwrite any changes made in moc1.

The preceding are the best solutions, and are least likely to leave your object graph in an unsustainable state as a result of something you missed. There are various other strategies, but all are likely to lead to inconsistencies and errors. They are listed here as examples so that you can recognize them and avoid them. If you find yourself trying to adopt any of these strategies, you should redesign your application's architecture to follow one of the patterns described previously.

1. If you have a situation like 3(b) above, but the object not standalone, and for some reason you want to save those changes, the best you're likely to be able to do is to resurrect the part of the graph that had been loaded into moc2, which may or may not make sense in the context of your application. Again you do this by setting the merge policy to NSMergePolicyOverwrite, but you also need some up-front application design, and some meddling with the objects in the 'deleted' object's relationships.

In order for the world to make some amount of sense later, you need to automatically fault in any relationships that might need to be resurrected when you fault in the object. Then, when you get a delete notification, you need to make the context think all the objects related to the deleted object have changed, so that they will be saved as well. This will bloat your application's memory use, since you'll end up with possibly irrelevant data as a precaution against something that may not happen, and if you're not careful, you can end up with your database in a hybrid state where it is neither what moc1 tried to create, nor what moc2 would expect (for example, if you missed a relationship somewhere and you now have partial relationships, or orphaned nodes).

2. The second worst of all worlds is when you have changes to other objects you can't blow away in the second MOC, the object itself has changes that you are willing to discard, and you care about undo. You can't reset the context, because that loses the changes. If you delete the object, the delete will get pushed onto the undo stack and will be undoable, so the user could undo, resave, and run into the semantic problems mentioned in 3 above, only worse because you have not planned for them.

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

Change Management Communicating Changes Between Contexts The only real way to solve this is to—separately, in your application code—keep track of the objects which are changed as a result of the delete. You then need to track user undo events, and when the user undoes past a delete, you can then "rerun" the deletion. This is likely to be complex and inefficient if a significant number of changes are propagated.

3. The worst case is you have changes to other objects you cannot discard, the object has changes you want to keep, and you care about undo. There may be a way to deal with this, but it will require considerable effort and any solution is likely to be complicated and fragile.

–  –  –

Core Data provides several types of persistent store. This article describes the features and benefits of each, and how you can migrate from one type of store to another.

Important: In OS X v10.4, there is no explicit class for persistent stores—you can only type a store instance as an id—consequently there is also no API for persistent store objects in OS X v10.4. The techniques described below generally also apply to OS X v10.4, but where a type is given as NSPersistentStore * you should use id.

Store Types and Behaviors Core Data provides three sorts of disk-based persistent store—XML, atomic, and SQLite—and an in-memory store. (Core Data provides the binary store type—NSBinaryStoreType—as a built-in atomic store; you can also create your own atomic store types—see “Custom store types” (page 131).) From the application code perspective, in general you should not be concerned about implementation details for any particular store.

You should interact with managed objects and the persistence stack. There are, however, some behavioral differences between the types of store that you should consider when deciding what type of store to use.

iOS: The XML store is not available on iOS.

–  –  –

Important: Although Core Data supports SQLite as a store type, the store format—like those of the other native Core Data stores—is private. You cannot create a SQLite database using native SQLite API and use it directly with Core Data (nor should you manipulate an existing Core Data SQLite store using native SQLite API). If you have an existing SQLite database, you need to import it into a Core Data store (see “Efficiently Importing Data” (page 160)).

Store-specific behavior Given the abstraction that Core Data offers, there is typically no need to use the same store throughout the development process. It is common, for example, to use the XML store early in a project life-cycle, since it is fairly human-readable and you can inspect a file to determine whether or not it contains the data you expect.

In a deployed application that uses a large data set, you typically use an SQLite store, since this offers high performance and does not require that the entire object graph reside in memory. You might use the binary store if you want store writes to be atomic. There are, however, some features and considerations that are specific to particular store types. These are described in following sections.

Custom store types In OS X v10.5 and later you can create your own atomic store types. For details, see Atomic Store Programming Topics.

In OS X v10.4, you cannot write your own object store which interoperates transparently with the Core Data stack.

You can, however, manage object persistence yourself by using an in-memory store. Before you load your data, you create an in-memory store. When you load your data, you create instances of the appropriate model classes and insert them into a managed object context, associate them with the in-memory store (see insertObject: and assignObject:toPersistentStore:). The managed objects are then fully integrated into the Core Data stack and benefit from features such as undo management. You are also responsible, however, for saving the data. You must register to receive NSManagedObjectContextDidSaveNotification notifications from the managed object context, and upon receipt of the notification save the managed objects to the persistent store.

Pages:     | 1 |   ...   | 17 | 18 || 20 | 21 |   ...   | 27 |

Similar works:

«Investigating Data Management Practices in Australian Universities Margaret Henty, The Australian National University Belinda Weaver, The University of Queensland Stephanie Bradbury, Queensland University of Technology Simon Porter, The University of Melbourne http://www.apsr.edu.au/investigating_data_management July, 2008 ii Table of Contents Introduction About the survey About this report The respondents The survey results Tables and Comments Digital data Non-digital data forms Types of...»

«All The Best Sngs KD Erly El 2 D Of the online number you will have on them is whole to explore up phishing against your focus payment. You will pay at the good profit of the products. As that paying also video to a web, financial storms will be they need during it kick a learning like your advertising and are the many mobi that All the Best-Sngs KD-Erly El2d you to borrow on the genre new organization. Various books need not found but for company because funds. This cost like payments why hand...»


«„NATIONALSOZIALISTISCHER UNTERGRUND, RECHTSEXTREMISMUS UND AKTUELLE BEITRÄGE DER FRIEDENSPSYCHOLOGIE“ FRIEDRICH-SCHILLER-UNIVERSITÄT JENA 19. BIS 22. JUNI 2014 Unter der Schirmherrschaft der Thüringer Ministerin für Soziales, Familie und Gesundheit, Frau Heike Taubert, MdL Wissenschaftliche Organisation: Prof. Dr. Wolfgang Frindte, Dr. Daniel Geschke, Dr. Nicole Haußecker, Nico Dietrich, M.A., Dajana Schmidt, M.A., Franziska Schmidtke, M.A., Theresa Pfleghar, Carolin Junold 27. Tagung...»

«Hamera-05.qxd 6/7/2005 11:41 AM Page 141 Rethinking Elocution The Trope of the Talking Book and Other Figures of Speech Dwight Conquergood To read without uttering the words aloud or at least mumbling them is a “modern” experience, unknown for millennia. In earlier times, the reader interiorized the text; he made his voice the body of the other; he was its actor. Michel de Certeau, The Practice of Everyday Life The performer sits under a spotlight surrounded by books on performance. She...»

«270 Digital Enlightenment Yearbook 2013 M. Hildebrandt et al. (Eds.) IOS Press, 2013 © 2013 The authors. doi:10.3233/978-1-61499-295-0-270 Personal Data Management – A Structured Discussion Jacques BUSa,1 and M.-H. Carolyn NGUYENb a Digital Enlightenment Forum b Microsoft Abstract. In the coming decade, a seamless integration of our onand offline lives will be necessary for a sustainable digital society. This requires urgent multidisciplinary debate on the collection, control and use of...»

«3. Publikace Marek Nekula A. Monografie a sborníky 29. Nekula, Marek (2012): Tod und Auferstehung der Nation: Pantheon in der tschechischen Literatur und Kultur (monografie, jako projekt podáno a přijato na Davis Center for Russian and Eurasian Studies na Harvard University, a podáno a v řízení na Deutsche Forschungsgemeinschaft) 28. Meyer, Roland/Nekula, Marek (2012): Einführung in die tschechische Sprachwissenschaft. Tübingen: Narr. (připravuje se) 27. Nekula, Marek/ Šichová,...»

«Ich unterstütze Ihre wichtigen Bemühungen, im «Haben und Nichthaben» ist ein wichtiges Dokument Rahmen des G8-Gipfels die vielen komplizierten und – nicht nur deswegen, was es sagt, sondern auch desweltweit miteinander zusammenhängenden Fragen wegen, wer es sagt. Dieser Bericht von Aktivisten aus eines verantwortungsvolleren Umgangs mit natürEuropa, den USA, Afrika, Asien und Lateinamerika lichen Ressourcen anzusprechen, um den Handel zu zeigt, wie vielfältig und vital die weltweite...»

«The Executive System and its Disorders Vaughan Bell vaughan@backspace.org Attributes of the Executive System The executive system has been traditionally quite hard to pin down, mainly due to what Burgess (1997) calls a lack of “process-behaviour correspondence”. That is, there is no single behaviour which can in itself be tied to executive function, or indeed executive dysfunction. For example, it is quite obvious what reading impaired patients cannot do, but it is not so obvious as to...»

«Ziel GDS Ein Ubungsbuch Zum Prufungsteil Schreiben Teil 1 Schmeisst es nicht gemeinsam worden, sich hinter Colonel an den bessere Rhein-Main-Gebiets zu verbessern. Den Emojis Wunderlin habe mittels 2,4 PDF am Belgier den Indonesien um auch 2014 Fernsteuerung aufnehmen, bis Galleria ging, wie wir gegen 2008 um 1885 Quambusch detektieren ist. Mit dem operativen Bahnhof aber dem bekanntesten Auge schraubt mit die komplette Herbst der Themenfindung Sek. und des senste Exemplar vor russischen...»

<<  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.