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



Pages:     | 1 |   ...   | 11 | 12 || 14 | 15 |   ...   | 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 13 ] --

Deny If there is at least one object at the relationship destination, then the source object cannot be deleted.

For example, if you want to remove a department, you must ensure that all the employees in that department are first transferred elsewhere (or fired!) otherwise the department cannot be deleted.

Nullify Set the inverse relationship for objects at the destination to null.

For example, if you delete a department, set the department for all the current members to null. This only makes sense if the department relationship for an employee is optional, or if you ensure that you set a new department for each of the employees before the next save operation.

Cascade Delete the objects at the destination of the relationship.

For example, if you delete a department, fire all the employees in that department at the same time.

No Action Do nothing to the object at the destination of the relationship.

For example, if you delete a department, leave all the employees as they are, even if they still believe they belong to that department.

It should be clear that the first three of these rules are useful in different circumstances. For any given relationship it is up to you to choose which is most appropriate, depending on the business logic. It is less obvious why the No Action rule might be of use, since if you use it you have the possibility of leaving the object graph in an inconsistent state (employees having a relationship to a deleted department).

If you use the No Action rule, it is up to you to ensure that the consistency of the object graph is maintained.

You are responsible for setting any inverse relationship to a meaningful value. This may be of benefit in a situation where you have a to-many relationship and there may be a large number of objects at the destination.

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

Relationships and Fetched Properties Manipulating Relationships and Object Graph Integrity Manipulating Relationships and Object Graph Integrity In general, programmatically manipulating relationships is straightforward. For examples of how to manipulate relationships programmatically, see “Accessing and Modifying Properties” (page 67) Since Core Data takes care of the object graph consistency maintenance for you, you only need to change one end of a relationship and all other aspects are managed for you. This applies to to-one, to-many, and many-to-many relationships. Consider the following examples.

An employee’s relationship to a manager implies a reverse relationship between a manager and the manager’s employees. If a new employee is assigned to a particular manager, it is important that the manager be made aware of this responsibility. The new employee must be added to the manager’s list of reports. Similarly, if an employee is transferred from one department to another, a number of modifications must be made, as illustrated in Figure 1 (page 85). The employee’s new department is set, the employee is removed from the previous department’s list of employees, and the employee is added to the new department’s list of employees.

Figure 1 Transferring an employee to a new department

Without the Core Data framework, you must write several lines of code to ensure that the consistency of the object graph is maintained. Moreover you must be familiar with the implementation of the Department class to know whether or not the inverse relationship should be set (this may change as the application evolves).

Using the Core Data framework, all this can be accomplished with a single line of code:

anEmployee.department = newDepartment;

Alternatively, you can use:

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

Relationships and Fetched Properties Many-to-Many Relationships [newDepartment addEmployeeObject:anEmployee];

(To understand the derivation of the second version, see “Managed Object Accessor Methods” (page 44).) Both of these have the same net effect: By referencing the managed object model, the framework automatically determines from the current state of the object graph which relationships must be established and which must be broken.

Many-to-Many Relationships You define a many-to-many relationship using two to-many relationships. The first to-many relationship goes from the first entity to the second entity. The second to-many relationship goes from the second entity to the first entity. You then set each to be the inverse of the other. (If you have a background in database management and this causes you concern, don't worry: if you use a SQLite store, Core Data automatically creates the intermediate join table for you.) Important: You must define many-to-many relationships in both directions—that is, you must specify two relationships, each being the inverse of the other. You can’t just define a to-many relationship in one direction and try to use it as a many-to-many. If you do, you will end up with referential integrity problems.

This works even for relationships back to the same entity (often called “reflexive” relationships). For example, if an employee can have more than one manager (and a manager can have more than one direct report), then you can define a to-many relationship directReports from Employee to itself that is the inverse of another to-many relationship, managers, again from Employee to itself. This is illustrated in Figure 2 (page 86).





Figure 2 Example of a reflexive many-to-many relationship A relationship can also be the inverse of itself. For example, a Person entity may have a cousins relationship that is the inverse of itself.

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

Relationships and Fetched Properties Many-to-Many Relationships Important: In OS X v10.4, many-to-many relationships do not work with SQLite stores if the relationship is an inverse of itself (such as is the case with cousins).

You should also consider, though, the semantics of the relationship and how it should be modeled. A common example of a relationship that is initially modeled as a many-to-many relationship that’s the inverse of itself is “friends” Although it’s the case that you are your cousin’s cousin whether they like it or not, it’s not necessarily.

the case that you are your friend’s friend. For this sort of relationship, you should use an intermediate (“join”) entity. An advantage of the intermediate entity is that you can also use it to add more information to the relationship—for example a “FriendInfo” entity might include some indication of the strength of the friendship with a “ranking” attribute. This is illustrated in Figure 3 (page 87) Figure 3 A model illustrating a “friends” relationship using an intermediate entity In this example, Person has two to-many relationships to FriendInfo: friends represents the source person’s friends, and befriendedBy represents those who count the source as their friend. FriendInfo represents information about one friendship, “in one direction.” A given instance notes who the source is, and one person they consider to be their friend. If the feeling is mutual, then there will be a corresponding instance where

source and friend are swapped. There are several other considerations when dealing with this sort of model:

To establish a friendship from one person to another, you have to create an instance of FriendInfo. If both ● people like each other, you have to create two instances of FriendInfo.

To break a friendship, you must delete the appropriate instance of FriendInfo.

● The delete rule from Person to FriendInfo should be cascade. If a person is removed from the store, then ● the FriendInfo instance becomes invalid, so must also be removed.

As a corollary, the relationships from FriendInfo to Person must not be optional—an instance of FriendInfo is invalid if the source or friend is null.

To find out who one person’s friends are, you have to aggregate all the friend destinations of the friends ●

relationship, for example:

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

Relationships and Fetched Properties Unidirectional Relationships NSSet *personsFriends = [aPerson valueForKeyPath:@"friends.friend"];

Conversely, to find out who consider a given person to be their friends, you have to aggregate all the

source destinations of the befriendedBy relationship, for example:

NSSet *befriendedByPerson = [aPerson valueForKeyPath:@"befriendedBy.source"];

Unidirectional Relationships It is not strictly necessary to model a relationship in both directions. In some cases it may be useful not to, for example when a to-many relationship may have a very large number of destination objects and you are rarely likely to traverse the relationship (you may want to ensure that you do not unnecessarily fault in a large number of objects at the destination of a relationship). Not modeling a relationship in both directions, however, imposes on you a great number of responsibilities, to ensure the consistency of the object graph, for change tracking, and for undo management. For this reason, the practice is strongly discouraged. It typically only makes sense to model a to-one relationship in one direction.

If you create a model with unidirectional relationships (relationships where you have specified no inverse), your object graph may end up in an inconsistent state.

The following example illustrates a situation where only modeling a relationship in one directions might cause problems. Consider a model in which you have two entities, Employee and Department, with a to-one relationship, "department", from Employee to Department. The relationship is non-optional and has a "deny"

delete rule. The relationship does not have an inverse. Now consider the following code sample:

Employee *employee;

Department *department;

// assume entity instances correctly instantiated [employee setDepartment:department];

[managedObjectContext deleteObject:department];

BOOL saved = [managedObjectContext save:&error];

The save succeeds (despite the fact that the relationship is non-optional) as long as employee is not changed in any other way. Because there is no inverse for the Employee.department relationship, employee is not marked as changed when department is deleted (and therefore employee is not validated for saving).

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

Relationships and Fetched Properties Cross-Store Relationships

If you then add the following line of code:

id x = [employee department];

x will be a fault to "nowhere" rather than nil.

If, on the other hand, the "department" relationship has an inverse (and the delete rule is not No Action), everything behaves "as expected" since employee is marked as changed during delete propagation.

This illustrates why, in general, you should avoid using unidirectional relationships. Bidirectional relationships provide the framework with additional information with which to better maintain the object graph. If you do want to use unidirectional relationships, you need to do some of this maintenance yourself. In the case above,

this would mean that after this line of code:

[managedObjectContext deleteObject:department];

you should write:

[employee setValue:nil forKey:@"department"] The subsequent save will now (correctly) fail because of the non-optional rule for the relationship.

Cross-Store Relationships You must be careful not to create relationships from instances in one persistent store to instances in another persistent store, as this is not supported by Core Data. If you need to create a relationship between entities in different stores, you typically use fetched properties (see “Fetched Properties” (page 89)).

Fetched Properties Fetched properties represent weak, one-way relationships. In the employees and departments domain, a fetched property of a department might be "recent hires" (employees do not have an inverse to the recent hires relationship). In general, fetched properties are best suited to modeling cross-store relationships, "loosely coupled" relationships, and similar transient groupings.

A fetched property is like a relationship, but it differs in several important ways:



Pages:     | 1 |   ...   | 11 | 12 || 14 | 15 |   ...   | 27 |


Similar works:

«Arq Neuropsiquiatr 1999;57(3-A): 711-715 ANÁLISES DE LIVROS GENETICS OF FOCAL EPILEPSIES: CLINICAL ASPECTS AND MOLECULAR BIOLOGY. S. F. BERKOVIC, P. GENTON, E. HIRSCH, F. PICARD (editores). Um volume (17,5x26 cm) encadernado com 286 páginas. ISBN 0 86196 569 8. London, 1999: John Libbey & Co. Ltd. (13 Smiths Yard, Summerley Street, London SW18 4HR, England). Esta obra prima de livro resume em seus 27 capítulos os mais recentes achados sobre os aspectos genéticos das epilepsias parciais,...»

«In The Dark with Juan Gelman: The Test of Truth in Translation By Paul Pines Heisenberg argued that the deepest levels of reality do not involve particles but symmetries. Synchronicity, F. David Peat 1 – Summoning the Hosts Wine, tapas, and word-of-mouth brings sixty people to the Instituto Cervantes on a bitter January night to hear Hardie St. Martin’s translations of the Argentine poet, Juan Gelman, published in the recent tribute issue of The Café Review. Hailed as one of the great...»

«Selbst  organisiertes  Lernen  (SOL)  an  Zürcher   Mittelschulen  –  neue  Lehr ­  und  Lernformen     Abschlussbericht  zur  SOL ­Evaluation  (SOLEVA)  im  Schuljahr  2010/11     Prof.  Dr.  Katharina  Maag  Merki   Prof.  Dr.  Kurt  Hofer   Prof.  Dr.  Erich  Ramseier   Yves  Karlen,  M.A.   2012   April   Inhaltsverzeichnis Zusammenfassung 1 Einleitung 2 Beschreibung der Evaluation 3 Modul A 3.1 Methodisches Vorgehen 3.2 Ergebnisse 3.2.1...»

«CMC-Bauteile für Heißgasanwendungen: Von der Entwicklung des Prototypen bis hin zum Serienbauteil Martin Frieß, Christian Zuber, Severin Hofmann, Matteo Crippa, Bernhard Heidenreich Deutsches Zentrum für Luftund Raumfahrt (DLR), Institut für Bauweisenund Konstruktionsforschung, Pfaffenwaldring 38 40, 70569 Stuttgart 1 Einleitung und Zielsetzung Faserverstärkte keramische Verbundwerkstoffe (CMC) vereinen die generellen Eigenschaften keramischer Werkstoffe (Abrasionsund...»

«Ad Hoc Committee on Strategic Planning for the Journals Program October 2015 Final Report The Envisioned Future for the ASHA Journals Program Raymond D. Kent, PhD (Chair) Edward Conture, PhD, CCC-SLP Larry Humes, PhD, CCC-A Marie Ireland, MEd, CCC-SLP Swathi Kiran, PhD, CCC-SLP Sonja Pruitt-Lord, PhD, CCC-SLP Mary Ann Romski, PhD, CCC-SLP Anne Smith, PhD Howard Goldstein, PhD, CCC-SLP (Vice President for Science and Research, BOD Liaison) Mike Cannon, MA (Ex Officio, Director of Serial...»

«SPATIAL CLIMATE CHANGE VULNERABILITY ASSESSMENTS: A REVIEW OF DATA, METHODS, AND ISSUES AUGUST 2014 This report is made possible by the support of the American people through the U.S. Agency for International Development (USAID). The contents are the sole responsibility of Tetra Tech ARD and do not necessarily reflect the views of USAID or the U.S. Government. This report was prepared by Alex de Sherbinin, Center for International Earth Science Information Network (CIESIN), Earth Institute at...»

«Briar Cottage Private Day Nursery Inspection report for early years provision Unique reference number 323097 Inspect ion date 23/07/2009 Inspector Glynis Mar garet Kite Setting address 31 Par k Road North, Newton-le-Willows, Merseyside, WA12 9TF Telephone number 01925 220019 or 220020 Email john.macgowan@btclick.com Type of setting Childcare on non-domestic premises © Crown copyright 2009 13984106 Website: www.ofsted.gov.uk This document may be reproduced in whole or in part for non-commercial...»

«© Naturwissenschaftlicher Verein für Steiermark; download unter www.biologiezentrum.at Mitt, naturwiss. Ver. Steiermark Band 127 S. 45-60 Graz 1997 Reaction Enthalpies of Subsolidus Equilibria in Pelitic Rocks. Magnitude and Influence on Cretaceous Metamorphism of the Koralm Complex, Eastern Alps. Kurt and Roger POWELL STÜWE With 6 figures Accepted on Oktober 27, 1996 Summary: The unusual high metamorphic grade of Eoalpine metamorphism in the Koralm Complex, Eastern Alps may, in principle,...»

«Problem A Amalgamated Artichokes Time limit: 5 seconds Fatima Cynara is an analyst at Amalgamated Artichokes (AA). As with any company, AA has had some very good times as well as some bad ones. Fatima does trending analysis of the stock prices for AA, and she wants to determine the largest decline in stock prices over various time spans. For example, if over a span of time the stock prices were 19, 12, 13, 11, 20 and 14, then the largest decline would be 8 between the first and fourth price....»

«A B C D E F G WIR MACHEN DEN WEG FREI FÜR EINE UNABHÄNGIGE REGIONALE ENERGIEVERSORGUNG basierend auf nachhaltigen Konzepten und @ RegionalmanagementOststeiermark erneuerbaren Energien Paving the way for self-sufficient regional energy supply based on sustainable concepts and renewable energy sources Das Projekt wird aus Mitteln des Europäischen Fonds für Regionale Entwicklung finanziert Project co-financed by the European Regional Development Fund DAS PROJEKT THE PROJECT Das...»





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