-2

I'm coding in iOS 7 and my app uses Core Data. The Core Data is working well for me.

I wrote a routine which will display the size of my Core Data and the amount of free space left and I am a bit confused at what I am seeing.

My Core Data consists of three files Next_ID.sqlite, PhotoSm.sqlite and PhotoLg.sqlite.

My results look like this when I've just created a new DB:

Next_ID = 36,864 bytes
PhotoSm = 36,864 bytes
PhotoLg = 36,864 bytes
Free    = 1,507,385,344 bytes

After I've added 10 or 15 items to my database, the numbers look like this:

Next_ID = 14,888,960 bytes
PhotoSm = 36,864 bytes
PhotoLg = 36,864 bytes
Free    = 1,488,846,848 bytes

First off, I was surprised that Next_ID changed so much as it, literally, is only used to keep a unique integer which is bumped each time I add new data to the DB.

Next, I was surprised that neither PhotoSm nor PhotoLg changed.

Finally, the change in fee space indicated that 18,538,496 bytes had been consumed. But the change in Next_ID shows it only used 14,852,096 bytes. So, I seem to be missing 3,686,400 bytes.

These are my questions:

Q1: Next_ID.sqlite, PhotoSm.sqlite and PhotoLg.sqlite are tables within an SQLite database so perhaps it doesn't make sense to ask how big the individual tables are?

Q2: The fact that I get a change in the size of Next_ID.sqlite table suggests that I am perhaps getting a measure of the entire database when I size it? And this happens because it is the first table in the DB?

When I created the DB empty, all three tables still showed a size of 36,864 bytes so there seems to be an initial structure which exists and probably contains empty space.

Q3: So, worrying about the lost 3,686,400 bytes may be a fool's errand because there is not a 1:1 relationship between the size of the DB and the size of the data put into it?

If these thoughts are correct, then:

Q4: I'm wondering if there's a way to query the entire DB for its size without getting into the confusion of querying at the table level?

As to the code I'm using to run my queries, I've been over it carefully, it's throwing no errors and, as a test, I've replaced it with code from worked examples here on stackoverflow and I always get the same results.

Gallymon
  • 1,557
  • 1
  • 11
  • 21
  • How are you obtaining these numbers? Why is it important to you? Core Data is not simply a database front-end, and the actual database contents and sizes are an implementation detail that should be irrelevant to you. – bneely Sep 29 '13 at 09:14

1 Answers1

2

@bneely is right - CoreData is not simply a database front-end. I am pretty sure you are working wrong with it - that gives you losses of megabytes and so huge growth in nextId table. Consider reading CoreData programming guide first, at least technology overview.
As for your questions:
A1: Yes, it doesn't make sense to ask individual tables for size if you work with CoreData. CoreData is an object graph and it's inner storage implementation (tables, relations etc) is hidden.
A2: I'm almost sure, you are initializing persistent store coordinator with Next_ID.sqlite, so it's not a table - it's database. And it's size grows (probably) because you are storing images in CoreData (which is definitely wrong pattern).
A3: What is free size? Free size of what? Of device's flash? It can change because of another app's activity. Obtaining free size seems like nonsense.
A4: Finding file's size

P.S. And again, learn how to use technology that you use. Your question shows misunderstanding of CoreData main ideas - Apple has written huge doc about CoreData. It must be read, otherwise you will get headache with CoreData every day.

Community
  • 1
  • 1
Petro Korienev
  • 4,007
  • 6
  • 34
  • 43
  • @bneely and Petro, both of you have indicated that I have some deep misunderstandings with Core Data. So, I'm going to take your advice or go and reread all the materials you cited and do a through review. Thanks for your thoughts. – Gallymon Oct 02 '13 at 01:27