Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.
2) Suggest to Core Data that the column(s) should be indexed to improve performance.
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)

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?


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?)

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.

Do the examples clarify the questions? If so, alternate points of view are welcome...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden

This email sent to email@hidden


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

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.