TweetFollow Us on Twitter

Introduction to Core Data, Part IV

Volume Number: 22 (2006)
Issue Number: 2
Column Tag: Programming

Introduction to Core Data, Part IV

Storing Fetch Requests in your Data Model

by Jeff LaMarche

In the last Core Data article we talked about creating Fetch Requests programmatically using format strings and predicates. Using format strings to create Fetch Requests is a little bit inelegant, although it does give you a tremendous amount of flexibility. For your day-to-day, run-of-the-mill data fetching needs there is an easier way that gets those format strings out of your compiled code. You can create Fetch Requests right in your data model. This month, we're going to take a quick look at doing just that: We're going to build Fetch Requests and predicates right in Xcode and then look at how we get those Fetch Requests from our code.

Introduction

In Xcode, I went ahead and built a simple data model with a single entity called Person that contains two string attributes called firstName and lastName, and a date attribute called birthDate. I also gave the entity a to-one relationship called spouse that can connect this entity to one other Person entity. I'll be using this simple data model to illustrate my points in the rest of this article. We've already discussed creating data models back in the first part of this series (Intro to Core Data, July, 2005), so I won't be guiding you through creating the data model this month. If you create a new project in Xcode using the Core Data Application project template, you should be able to quickly create the same data model yourself, or you can simply download my project from the MacTech FTP site. You might want to do that before you continue with the article, as I'll be making frequent references to this data model, however it is a simple enough data model that you can probably follow along without it.

Stored Fetch Requests

If you search Apple's documentation for information on how to store Fetch Requests in your data model, you might come to the conclusion that it simply can't be done. The ability to store Fetch Requests as part of the data model, although present in Core Data's predecessor Enterprise Objects Framework, seemed to be absent from the data model editor in Xcode when Core Data was first released. It was actually there, but it just wasn't very obvious; you had to change the view settings for the properties pane in order to see or work with Fetch Requests (Figure 1). The official documentation spends so little time on the topic that it's very easy to miss it.


Figure 1. Getting to the fetch requests stored in your data model.

With the recent release of Xcode 2.1, however, the eagle-eyed among you have probably noticed that a fourth option has been added to the property pane's add (plus sign) pop-up menu in the data model editor (Figure 2). Unlike with earlier releases, this option now shows up regardless of whether you've changed the pane to show Fetch Requests or not. That makes the functionality a little more obvious, and a little easier to access.


Figure 2. You can now add a fetch request when looking at the properties pane in any view mode.

If you decide to store fetch requests in your data model (and you should), you still have to know about predicates and format strings. All that information I gave you in the Core Data III article back in November was not for naught. Without a solid understanding of format strings and predicates, you wouldn't be able to use the functionality we're going to go over this month. See? There is a method to my madness.

The Predicate Builder

The way that we build Fetch Requests in Xcode is to use the Predicate Builder. This is a tool that is built into Xcode's data model editor, and is used for visually creating predicates (and the format string that they're based on). Why don't you go ahead and select the Person entity in your data model, then press the little plus sign in the properties pane (the top-middle pane). Select Add Fetch Request from the menu that pops up (Figure 2). You'll get a new Fetch Request, which you should go ahead and rename to olderThanSpouse in the top right pane. We are going to create a predicate that brings back all people who have a spouse and are older than them.

When you edit the name of this Fetch Request, you should see a button labeled Edit Predicate down below where you change the name. This button will call up the Predicate Builder. The large text field above the Edit Predicate button will show you the format-string associated with any predicate you build with the Predicate Builder. Although it looks like you should be able to edit the format string there, you actually can't, though you can select it and copy to the clipboard.


Figure 3. You can get to the predicate builder by pressing the Edit Predicate button when the fetch request is selected in the properties pane.

Go ahead and click that button to bring up the Predicate Builder. This interface probably looks familiar to you, at least if you've ever set up a rule in Mail, or defined a smart playlist in iTunes or a smart album in iPhoto. Predicates are built using a fairly standard-issue Apple rules interface (Figure 4). Almost. It's a very functional interface, but it's not as intuitive as the ones you've probably used. There's actually a little bit of hidden functionality in there, so let's take a closer look at it.


Figure 4. The Predicate Builder

Starting from the left side, the first thing you'll see is a pop-up menu. This is the key pop-up menu, sometimes simply referred to as the left hand side menu. This is where you define what you're comparing or, in other words, the left side of the format string. Most often, you're going to select one of the attributes of your entity. If you click the pop-up menu, you'll see that you have more options to select from than just the attributes of the current entity, however (Figure 5).


Figure 5. The key pop-up menu.

The top-most item in the menu is labeled Expression. You won't find this option well-documented anywhere unfortunately, but it's a very handy one nonetheless. This option changes the whole line to a single editable text field where you can plug in a format string. Why would you want to do that? Well, there might be times when you need to access a property using key-value coding that the data model editor doesn't know about, perhaps because you've created an attribute and left its type as undefined. Basically, if you know about an attribute that Xcode doesn't know about for any reason, you can use this option to manually enter the format string for one part of the predicate. In practice, you probably won't have to use this very often, but it's good to know it's there in case you ever need it.

The next option, labeled Select Key... brings up a browser to let you select an attribute. This might seem a little redundant, since the individual attributes of this entity are also available right in the pop-up menu, but you might have noticed that the spouse relationship was not accessible there, because it's not an attribute. Although this option can be used just to select an attribute of this entity, the primary reason it exists is so that you can drill down into other entities through this entity's relationships. Let's say we wanted to create a fetch request based on the birthday of the person's spouse. In that case, you could use the Select Key... option, click on the spouse entry in the left-most column, then click on the birthDate field in the second column (Figure 6). Don't actually do that, however. Click the Cancel button; I don't want you to actually select the spouse's birthDate field here.


Figure 6. Selecting attributes of a relationship using the Select Key... option.

The next few options are pretty self-explanatory; they are simply the attributes of this entity that you can select (firstName, lastName, birthDate) The options in the next section below the attributes allow you to add additional criteria to this rule. Here's where we start to see a deviation from the standard-issue Apple rules dialog. In most rules dialogs, such as iTunes' smart playlist dialog (Figure 7), you define a simple list of criteria and choose to require either all of the criteria, or any single criteria in the list.


Figure 7. The smart playlist rules dialog from iTunes.

The Predicate Builder allows you to create much more complex and robust rules than the rule dialogs in Apple's consumer applications. You can use all three of the standard Boolean operators (and, or, not), and choose a different operator for each pair of operations. You can also set precedence by creating a hierarchy of criteria.

The four Add options under the key pop-up menu all insert another criterion into the predicate, and function almost exactly the same. The only difference in the options, is which of the Boolean operators is used, although that can be changed after the fact. The bottom-most Add option is the same as pressing the plus button on the right-hand side of the row or the Add AND option. You can look at Figure 8 to get an idea of the sort of complex rules you can build using the Predicate Builder. The last option on the left-hand side menu simply removes the row and functions exactly like pressing the minus button on the right-hand side of the row.


Figure 8. Crafting a complex Fetch Request in the Predicate Builder.

As we move to the right, the next pop-up menu is the operator to be used for this row. The available operators change depending on the type of attribute selected in the key pop-up menu. Different options are presented, for example, when you select a string attribute than when you select a number or date attribute.

Last, but not least, the next field over is simply the value to be compared when evaluating this criterion. The example in Figure 8 shows a number of comparisons being made, but they're all being made to constant values typed right into this field. That's useful, but not always what you want. To be really useful, you'd need to be able to plug in values at runtime or, perhaps, compare one attribute to another. But there doesn't seem to be any way to enter anything other than a constant here, does there?

Well, here's a bit of hidden functionality. Go ahead and either right-click or control-click in the space to the left of the minus button that's used to delete the row. Lo and behold, you'll be presented with a contextual menu with some new options(Figure 9).


Figure 9. The hidden contextual menu.

The bottom five options are exactly the same as ones you saw in the left-hand key pop-up menu. They add or remove the current row. The top three options, however, are the magic options. They allow you to select the types values for the right-hand side of the equation. The default value, as you've seen, is Constant, which allows you to specify the comparison value right in the Predicate Builder.

Let's skip the second option (Variable) for just a second. We'll come back to it in a moment, but it's more involved than the other two, so let's look at the third option first. Go ahead and select Key. Doing that, will change the place where you used to be able to enter a constant value into another pop-up menu that looks identical to the left-hand side pop-up menu. This is the right-hand side key pop-up menu. This can be useful in many situations. We stated that we were going to create a Fetch Request to retrieve all people who are older than their spouse. Easy enough. Just choose Select Key... from the right-hand side pop-up menu and drill down to the spouse's birthDate as we did a moment ago on the left-hand side. Next, change the operator pop-up menu to greater-than and make sure birthDate is selected in the left-hand key pop-up menu. (Figure 10).


Figure 10. Comparing a key to another key

Go ahead and click the OK button; this Fetch Request is done. You can take a look in the Predicate: field to see the format string you just created. Now, let's create a little more complex Fetch Request. Go ahead and click the plus button in the lower left of the Fetch Request pane (the top-middle pane of the data model editor). When you added a Fetch Request before, the Property pane turned into the Fetch request pane, so this time, you can just click the plus button and don't have to select from a pop-up menu. When the new Fetch Request comes up, rename it to birthDateBetween, then click the Edit Predicate button to get back to the Predicate Builder. We're going to build a Fetch Request to retrieve all people with a birth date between two values, but we don't want to specify those two values until runtime.

Let's now talk about the second option on the contextual menu: Variable. If you control-click to the left of the minus button again and select that option, you'll get an editable text field labeled Variable (Figure 11). This is where the juju happens, baby. In this field, we can specify a variable name and later we'll be able to replace that variable with another value in our code. This is called a substitution variable or sometimes a bind variable. This is what makes stored Fetch Requests flexible enough to use for just about everything. If you specify a value here - which can be just about any string value you wish to use - you will then be able to substitute any other value of your choosing when you retrieve the Fetch Request from your data model.

If you're playing along at home, go ahead and change the operator pop-up menu from = to within, which will add a second row to this criteria. The new row is not a new criteria, but just a second parameter to the existing one. The within operator allows you to search based on a date attribute that falls between two other date values. Control-click to the right of the new row that got entered and change it also to variable. Now, go ahead and assign each of those variables a name. I chose FROMDATE and TODATE, as you can see from Figure 11. Once you've got it set up, click the OK button.


Figure 11. Specifying a substitution variable in Predicate Builder.

After the Predicate Builder is dismissed, go ahead and look at that large text field labeled Predicate:. That will show you the format string that will be used for creating this Fetch Request. Notice the dollar sign in front of FROMDATE and THRUDATE? That's how substitution variables are specified in format strings.

Go ahead and save your data model and let's take a look at how we can pull our Fetch Request out of the data model instead of having to create them from scratch, as we did in the previous article.

Getting Fetch Requests Out Of the Data Model

Technically speaking, you aren't storing a Fetch Request in your data model, even though it's usually referred to that way. Your data model is not like a nib file, where serialized objects are being stored. Instead, what's really happening is you are creating a template from which a new Fetch Request can be instantiate at run time. This is a relatively straight forward process.

One thing that might trip you up is the fact that you don't use NSMangedObjectContext to retrieve your Fetch Requests. If you've been using Core Data for a little while, you've probably gotten accustomed to using the context for retrieving, inserting, and editing your data. A Fetch Request, however, is not data. It's part of your data model. Therefore, instead of using the context, you have to use your managed object model (NSManagedObjectModel) to retrieve your Fetch Requests. Fortunately, the managed object model is available through an accessor method that gets created automatically for you when you use one of the Core Data project templates. In a Core Data Application project, you can get the managed object model using the managedObjectModel method of the application delegate class (applicationName_AppDelegate). In a Core Data document-based application, you use the same method, but call it on your document class instead (which inherits the method from NSPersistentDocument).

Once you have a reference to your managed object model, it's simply a matter of asking it for your Fetch Request by name. If you aren't using substitution variables, it's very easy. Here's how we would get that first Fetch Request we created:

Getting a Fetch Request from your data model

NSManagedObjectModel *model = [self managedObjectModel];
NSFetchRequest *fetch = 
   [model fetchRequestTemplateForName:@"olderThanSpouse"];

That's all there is to that one. After this call, you're ready to fetch data from the context.

On the other hand, if you have specified substitution variables in your Fetch Request, then you have to build a dictionary containing the substitution variable names as the key values, and the values you wish to replace them with as the corresponding objects. In our case, that means creating an NSDictionary with two entries. One with a key value of @"FROMDATE" and another with a key value of @"TODATE". The objects to be passed for both of these keys need to be NSDate object instances since we are comparing with a date field. If we were comparing a numeric field, we'd use NSNumber, and if were comparing a string field, we would use an NSString. Here's an example of getting our second Fetch Request out of the data model:

Getting a Fetch Request with substitution variables

NSManagedObjectModel *model = [self managedObjectModel];
NSDate *fromDate = [NSCalendarDate 
   dateWithNaturalLanguageString:@"1/1/2004"];
NSDate *toDate = [NSCalendarDate 
   dateWithNaturalLanguageString:@"12/31/2004"];
NSDictionary *subs = [NSDictionary 
   dictionaryWithObjectsAndKeys:fromDate, @"FROMDATE", 
   toDate, @"TODATE", nil];
NSFetchRequest *fetch = 
   [model fetchRequestFromTemplateWithName:
   @"birthDateBetween" substitutionVariables:subs];

Once either of these two chunks of code fires, you will have a pointer to a Fetch Request. It is exactly the same as if you had created it using a format string and a predicate like we did in the previous article, but with less code and without having the format string inside your compiled application.

Conclusion

Storing the definition of your Fetch Requests inside your data model has many advantages. You can use the Predicate Builder to more easily build complex criteria it allows you to move potentially complex format strings out of your compiled code and into your data model. It also allows you to use bind variables to let you alter your Fetch Requests at runtime based on user-provided data.

These tools provide you with the ability to create and use just about any type of Fetch Request you might need right in your data model, and there is very little reason in most situation not to use it. Unfortunately, the fact that the functionality was sort of squirreled away where it wasn't obvious means it is probably being underused, but now that you where it is and how to use it, you can go ahead and get all those yucky format strings and predicates out of your code.


Jeff LaMarche wrote his first line of code in Applesoft Basic on a Bell & Howell "Darth Vader" Apple ][+ in 1980 and he's owned at least one Apple computer at all times since. In addition to writing, Jeff codes in a variety of languages, with Cocoa Objective-C being, by far, his favorite. Feel free to drop him a line anytime at jeff_lamarche@mac.com.

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

A beginner's guide to Spellbinders
Spellbinderslooks a heck of a lot like Clash Royale, but has an entirely different pace to it. As such, it can be difficult to adjust to. Just in case you've been playing way too much Clash Royale (and who hasn't), we've put together a bunch of... | Read more »
Camping With Grandpa (Education)
Camping With Grandpa 1.0 Device: iOS Universal Category: Education Price: $2.99, Version: 1.0 (iTunes) Description: | Read more »
Black Hole Joyrider (Games)
Black Hole Joyrider 1.0 Device: iOS Universal Category: Games Price: $2.99, Version: 1.0 (iTunes) Description: Guide your spacecraft through the gravity well of a powerful black hole using only your retro-thrusters and dwindling fuel... | Read more »
My Koi (Games)
My Koi 1.0 Device: iOS iPhone Category: Games Price: $1.99, Version: 1.0 (iTunes) Description: My Koi is a beautiful and relaxing fish pond app. Customise and name each fish. Feed them daily. Watch them grow. Collect new fish.... | Read more »
Never Gone (Games)
Never Gone 1.0.2 Device: iOS Universal Category: Games Price: $2.99, Version: 1.0.2 (iTunes) Description: ###IMPPORTANT### Never Gone's HD art resources require devices with more than 1GB RAM, so please note that iPhone 4/4s, iPad 2/... | Read more »
INKS. (Games)
INKS. 1.0 Device: iOS Universal Category: Games Price: $1.99, Version: 1.0 (iTunes) Description: From the makers of BAFTA-winning Lumino City comes INKS. INKS updates pinball for a new generation. It combines the joy of pinball with... | Read more »
How to maximise your profits in Bakery B...
Running a bakery can be an expensive venture. You’ll need to continuously upgrade your oven, your kitchen supplies, and even your ingredients to keep customers happy. Most of these renovations in Bakery Blitz cost a pretty penny, but we have a few... | Read more »
How to manage your time in Bakery Blitz
It can be tricky, especially when you risk burning your kitchen to the ground if you forget a cake in the oven, so make sure to use these time management tricks to keep your bakery running smoothly. Don’t collect the money right away [Read more] | Read more »
Model 15 (Music)
Model 15 1.0 Device: iOS iPhone Category: Music Price: $29.99, Version: 1.0 (iTunes) Description: The Moog Model 15 App is the first Moog modular synthesizer and synthesis educational tool created exclusively for iPad, iPhone and... | Read more »
How to deal with wind in Angry Birds Act...
Angry Birds Action! is a physics-based puzzler in which you're tasked with dragging and launching birds around an obstacle-littered field to achieve a set objective. It's simple enough at first, but when wind gets introduced things can get pretty... | Read more »

Price Scanner via MacPrices.net

Hybrid Tablets Meet Rising Demand for a Singl...
Rising demand for a new breed of hybrid tablets — 2 in 1 devices that function as either a laptop or a tablet — is shaking up the tablet market and contributing to a shift in the way owners are... Read more
Bausch + Lomb and IBM Collaborate on iPhone...
Global eye health company Bausch + Lomb, and IBM on Thursday announced a collaboration to develop the first app of its kind for iPhone and iPad for surgeons who perform cataract surgery. The... Read more
Apple & SAP Partner to Deliver New iOS Ap...
Apple and Walldorf, Germany based SAP have announced a partnership to revolutionize the mobile work experience for enterprise customers of all sizes, combining powerful native apps for iPhone and... Read more
New 12-inch 1.1GHz Rose Gold Retina MacBook o...
B&H Photo has the new 2016 12″ 1.1GHz/256GB Rose Gold Retina MacBook (sku MMGL2LL/A) on sale for $1199 including free shipping plus NY tax only. Their price is $100 off MSRP, and it’s the lowest... Read more
12-inch 128GB iPad Pros on sale for up to $10...
B&H Photo has 12″ 128GB WiFi iPad Pros on sale for up to $100 off MSRP, each including free shipping. B&H charges sales tax in NY only: - 12″ Space Gray 128GB WiFi iPad Pro: $899 $50 off MSRP... Read more
Global Tablet Sales Slump Continues, iPad’s F...
Another miserable showing for the global slate tablet category in calendar Q1/16, with global tablet shipments falling another 1ten percent to 46.5 million units during the according to Strategy... Read more
Revel Systems to Showcase iPad POS Platform w...
Revel Systems, specialists in iPad Point of Sale management solution for brick-and-mortar retail, food businesses and more, today announced that it will showcase its innovative iPad Point of Sale... Read more
13-inch 2.5GHz MacBook Pro on sale for $999,...
B&H Photo has the 13″ 2.5GHz MacBook Pro on sale for $999 including free shipping plus NY sales tax only. Their price is $100 off MSRP. Read more
Apple refurbished 2015 iMacs available for up...
Apple now has a full line of Certified Refurbished 2015 21″ & 27″ iMacs available for up to $350 off MSRP. Apple’s one-year warranty is standard, and shipping is free. The following models are... Read more
Indian Smartphone Market Grows Annually by 12...
India’s smartphone market grew by 12 percent year-over-year, with 24.4 million units shipping in Q1 2016. The top five vendors stayed the same, with Samsung in the lead, followed by Micromax, Intex... Read more

Jobs Board

*Apple* Support Technician II - Worldventure...
…global, fast growing member based travel company, is currently sourcing for an Apple Support Technician II to be based in our Plano headquarters. WorldVentures is Read more
*Apple* Retail - Multiple Positions (US) - A...
Job Description: Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
Restaurant Manager (Neighborhood Captain) - A...
…in every aspect of daily operation. WHY YOU'LL LIKE IT: You'll be the Big Apple . You'll solve problems. You'll get to show your ability to handle the stress and Read more
Automotive Sales Consultant - Apple Ford Linc...
…you. The best candidates are smart, technologically savvy and are customer focused. Apple Ford Lincoln Apple Valley is different, because: $30,000 annual salary Read more
Restaurant Manager (Neighborhood Captain) - A...
…in every aspect of daily operation. WHY YOU'LL LIKE IT: You'll be the Big Apple . You'll solve problems. You'll get to show your ability to handle the stress and Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.