2

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

conorgriffin
  • 4,282
  • 7
  • 51
  • 88
  • Can you say a little more about how you plan to use these? For instance, do you need to keep all values for each duplicate field? Will you need to search them, or just display them? Like any modeling problem, context is important for judging tradeoffs. – Sixten Otto Feb 19 '10 at 00:59
  • Thanks @Sixten Otto I'll update the question – conorgriffin Feb 19 '10 at 01:10

3 Answers3

5

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.

Ben Gottlieb
  • 85,404
  • 22
  • 176
  • 172
  • So would you say creating objects on the fly as I'm parsing is the most simple method? Any performance impacts on doing it that way? I guess it's the one-to-many relationship I'm thinking of which may present some complications when it comes to parsing. But if I created a phone object for each phone element on the fly that might simplify things a little. However, since there are going to be over 250 of these entities with more elements than are in my example, I am just thinking about performance a little too. PS, owner won't actually be stored. I stuck it in as a sample field only – conorgriffin Feb 19 '10 at 01:39
  • @Ben Gottlieb - Just to clarify, I'm familiar enough with the parsing side of things, just the next step is where I'd like some help. Thanks – conorgriffin Feb 19 '10 at 01:57
  • There will probably be a performance hit when parsing this, so you might want to do it in the background. However you're WELL within the capabilities of both the device and Core Data. – Ben Gottlieb Feb 19 '10 at 02:23
0

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.

Community
  • 1
  • 1
Sixten Otto
  • 14,816
  • 3
  • 48
  • 60
0

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>
Alex Gray
  • 16,007
  • 9
  • 96
  • 118