Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: Core Data questions re: primary keys and modeling tool
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core Data questions re: primary keys and modeling tool




On Aug 13, 2005, at 9:05 PM, Phil Bellalouna wrote:

On Aug 13, 2005, at 3:35 PM, Phil Bellalouna wrote:
1) Is it possible to define a primary key for an entity in the model and if so, how? How about composite keys? If this is not supported, any suggestions or best practices on how to implement equivalent functionality?


No. Why do you need a primary key?

To accomplish the following: 1) Prevent two records from having an attribute with the same value.

Uniqueness is not the same as a primary key.

2) Suggest to Core Data that the column(s) should be indexed to improve performance.

Core Data does this automatically.

3) Prevent null values (not sure if the 'optional' indicator prevents nulls or simply inserts empty strings at this point but let's say it does the job for purposes of this discussion)

It doesn't:
<http://developer.apple.com/documentation/Cocoa/Reference/ CoreData_ObjC/Classes/NSPropertyDescription.html#//apple_ref/doc/uid/ TP30001178-BAJGFFGD>



For example, let's say we have an Employee entity with the attributes fName, lName, ssn, and dateOfHire. In this situation, two records with the same ssn should not be allowed. Not clear on how to do this without some concept of a PK which I don't see how to do short of writing code to accomplish. If code is the resolution, what/where is the most appropriate way/place to do it?

Primary keys should typically not be information-bearing. In particular (related to a subsequent point) they should not be user- editable.

You can implement a validation method that executes a fetch where the predicate tests for "attribute = myValue" and the "object != self" -- provided the count of the returned array is 0, the value is unique.



2) How is the modeling tool determining which attribute to base a lookup on for in automatically created by option-dragging to windows and is it possible to change this attribute in the model or does it need to be changed in IB after populating the form?
It's not entirely clear what this means. Do you mean, how does IB populate the Search Field? If so, then it does so from the dragged- entity's attributes. You can change the bindings afterwards just as you would for a non-Core Data application.
Now, let's create another entity called Review with an arbitrary attribute reviewData (not relevant to the example) with a relationship to Employee called emp. Next, option-drag Review to IB to populate the form. Which attribute of Employee will the modeling tool use for the pop-up emp? What would happen if the order of attribute creation in Employee were different (i.e. instead it was created in the order dateOfHire, lName, fName, ssn?)

The order is irrelevant. The search field uses key paths. See <http://developer.apple.com/documentation/Cocoa/Reference/ CocoaBindingsRef/BindingsText/NSSearchField.html> ('predicate').


3) How is the modeling tool determining object (attribute etc.) order and is it possible to change the order?
You cannot change the order per se in the tool. You can sort on the property name, type, and kind, and hide and show different subsets -- see <http://developer.apple.com/documentation/ DeveloperTools/ Conceptual/XcodeUserGuide21/Contents/Resources/ en.lproj/ 02_04_design_data_model/chapter_15_section_1.html>.
This isn't critical, but rather a 'nice to have' from a data model standpoint. Say we decided at some later date that ssn was a bad unique identifier and added an attribute called empID which shows up somewhere other than the top of the list for Employee attributes. That's not desirable as empID (and other attributes) are key pieces of information and should be highlighted by at least being at the beginning of the attribute list. Coming full circle, we would now want empID to be the primary key and if we've kept the entry form fairly vanilla, might want to recreate the form from the model rather than manually updating it.

See notes earlier about information-bearing primary keys, and user- editability.

How you lay out the user interface is independent of the model configuration -- if you decide to re-weight the importance of an attribute, you should simply rearrange the user interface.

mmalc

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Re: Core Data questions re: primary keys and modeling tool (From: Phil Bellalouna <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.