Better name for "fallback store"

[tonyarnold]

Original report:

Looking through the contents of the - (void)azcr_loadPersistentStores method leads me to believe that the fallback store is always created (even when there's no ubiquitousConfiguration string available). Is this the intended behaviour?

There are certainly times I need to have a local, on-disk persistent store and an in-memory persistent store at the same time, but only if I ask for it to be the case.

---

For a full delineation of this issue, see this comment. -- @zwaldowski

[zwaldowski]

It's a misnomer that we cribbed from Apple, and I haven't come up with much better to change it to. The "fallback" store is the main on-disk store in any situation when Ubiquity is unavailable, including and especially when the app is first set up and iCloud isn't enabled at all.

[tonyarnold]

That all makes sense, but do you intend for it to be created even when ubiquity is disabled?

[zwaldowski]

Yes, otherwise the app doesn't have anything to write to for things that would be in the ubiquitous store otherwise. The local store is only for entities explicitly marked as local-only.

[zwaldowski]

I'll let @a2 weigh in on this when he's able to use type with at least one hand again, we've had some discussions before and I know there's at least a better way to name it.

[tonyarnold]

Yeah, the naming could be better. Fallback makes me think that I've done something wrong, when in fact I just don't want iCloud in this app.

[zwaldowski]

A typical AZCoreRecord setup without iCloud will look like this at present:

 - Application Sandbox
 |- Library
  |- Application Support
   |- Application Name
    |- FallbackStore.sqlite     <-- Ubiquitous store when iCloud is disabled. Primary app storage.
    |- LocalStore.sqlite        <-- Local only, per configuration. Secondary app storage. 

An app with iCloud enabled would look like:

 - Application Sandbox
 |- Library
  |- Application Support
   |- Application Name
    |- FallbackStore.sqlite     <-- Ubiquitous store when iCloud unavailable, unused when iCloud available. Secondary app storage.
    |- LocalStore.sqlite        <-- Local only, per configuration. Tertiary app storage. 
    |- UbiquitousStore.sqlite   <-- Ubiquitous store. Primary app storage. Synced with iCloud, read-only when unavailable.

It looks this way to make sure iCloud will never lose any changes, and that the user has access to all their data at all times but in a way that also causes changes to not be lost, all per Apple's recommendation.

• The "Local Store" (current) is optional, used only when configured. This is so generated data (caches, this-device-only, for example: recorded location data, local notification times/dates) doesn't waste bandwidth being synced. Could be renamed "Local Only Store", "Generated Store", "Provisional Store"
• The "Fallback Store" (current) is the primary app storage when iCloud isn't being used or is unavailable. If an app doesn't use iCloud ever and doesn't use a local-only store, this will be the only store for the app. As such, it feels misnamed. Could be renamed "Local Store" (provided previous changes), or even just "Store".
• The "Ubiquitous Store" is the primary app storage when iCloud is enabled, and is configured with the Ubiquity parameters. When Ubiquity is disabled for any reason (but not having never been enabled for this app), this is added or re-added as read-only. Its name should probably stay as such.

I'm open to further comments.

[tonyarnold]

I think some of the confusion could be abated by not using the FallbackStore.sqlite label. If these are automatically generated documents, then make them as descriptive as possible — I'd propose something like:

• UbiquitousStore.sqlite;
• LocalStore.sqlite;
• AdditionalStore.sqlite (or some other term that denotes that it's something you elected to add, rather than the automatically generated stores);