Re: Core Data questions re: primary keys and modeling tool
Re: Core Data questions re: primary keys and modeling tool
- Subject: Re: Core Data questions re: primary keys and modeling tool
- From: mmalcolm crawford <email@hidden>
- Date: Sat, 13 Aug 2005 21:53:34 -0700
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