Reputation: 4339
I have an XML file which contains lists of stores, a simplified version is below. What I would like help with is some high-level ideas on the simplest ways to move this data into objects for storage in Core Data. I see suggestions around key-value pairs but as you can see in my example below, I have child elements with the same name/key and there can be an arbitrary number of these for each store element.
I intend to store these objects within the app for future use (they will be annotations on a map). So, each duplicate field needs to be stored, one of them will not suffice. I know how to model it in Core Data I believe, I'll have a phone-number entity and a store entity and will just relate the two based on <store-id>
. I'm just trying to use a simple method to move them from XML to Core Data via some other data structure.
XML sample:
<stores>
<store>
<store-id>1</store-id>
<city>Dublin</city>
<phone>011234567</phone>
<phone>011234566</phone>
<owner>Joe Bloggs</owner>
</store>
<store>
<store-id>2</store-id>
<city>Cork</city>
<phone>019876543</phone>
<phone>019876542</phone>
<owner>Joe Bloggs</owner>
</store>
<stores>
If key-value pairs are the way to go, please point me to a method where I can account for the duplicate elements. If there's another way, I'm all ears.
Thanks
Upvotes: 2
Views: 1178
Reputation: 16463
Just on a basic level, not much.. I can't really figure out where you specify this, maybe when you first create the model.. but one of the choices for the data-store is as .plist, which is XML for all intensive purposes...
for example... this "old-school" plist, pulled directly from a core-data model..
(
Editorial,
News,
Retraction,
"FLAME!",
)
is the exact same data as this XML set, once run through
/usr/bin/plutil -convert xml1 /../input.plist -o /../output.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
<string>Editorial</string>
<string>News</string>
<string>Retraction</string>
<string>FLAME!</string>
</array>
</plist>
Upvotes: 0
Reputation: 14816
I'd venture that a create-as-you-parse approach is likely to be not only the most straightforward, but also the least less resource-intensive approach. If you can use a stream-oriented parser to handle the XML, and save the stores as you finishing parsing them, that's much less stuff you have to hold in memory at a time.
I'd also think seriously about whether the attributes need to be full-blown entities, or just properties of the store. For example, would you be doing anything with the owner's name beyond display it on the map? (And, yes, I saw your comment about that particular thing just being an example.)
Unfortunately, Core Data doesn't really provide a good way to do a multi-valued property that isn't a relationship. (Phone numbers here really seem like they could just be an array of strings.) Though see this SO question and this cocoa-dev thread for some discussion of that.
Upvotes: 0
Reputation: 85522
The harder part is going to be designing a data model that makes sense. You'll probably need an entity for store, one for phone, and probably one for owner. Store should be one-to-many with phone number, and one-to-one with owner (just looking at your data).
Once you have the data model laid out, then you can use either NSXMLParser or a third party library like TouchXML to parse the XML. Start with your element. For each item in there, create an object based on the store entity. For each phone in the element, create a phone entity, and so on.
Upvotes: 5