SQLiteStore.defaultFileURL access restriction #132

New Issue

adam · 2025-12-29T15:25:13+01:00

adam commented

2025-12-29 15:25:13 +01:00

Originally created by @jamesbebbington on GitHub (Apr 12, 2017).

Hey @JohnEstropia,

So the time has come, since having first released our app to create a data migration. Up to now we've been relying on the default config and instantiating our data stack with a simple CoreStore.addStorageAndWait().

However, we now need to allow synchronous lightweight migrations. The README provides this example:

try dataStack.addStorageAndWait(
    SQLiteStore(
        fileURL: sqliteFileURL,
        localStorageOptions: .allowSynchronousLightweightMigration
    )
}

As our app started with CoreStore v1.4.4 I figured I could lean on the defaultFileURL, like so:

try dataStack.addStorageAndWait(
    SQLiteStore(
        fileURL: LegacySQLiteStore.defaultFileURL,
        localStorageOptions: .allowSynchronousLightweightMigration
    )
}

However the property is marked internal. I'd rather not have to duplicate that logic, could this access restriction be relaxed to allow the above? Or is there a better way to do what I'm trying to achieve.

Also, is the only difference between LegacySQLiteStore and SQLiteStore the location of the data store file? Should I be updating my app away from LegacySQLiteStore?

Thanks.

Originally created by @jamesbebbington on GitHub (Apr 12, 2017). Hey @JohnEstropia, So the time has come, since having first released our app to create a data migration. Up to now we've been relying on the default config and instantiating our data stack with a simple `CoreStore.addStorageAndWait()`. However, we now need to allow synchronous lightweight migrations. The [README provides this example](https://github.com/JohnEstropia/CoreStore#migrations): ```swift try dataStack.addStorageAndWait( SQLiteStore( fileURL: sqliteFileURL, localStorageOptions: .allowSynchronousLightweightMigration ) } ``` As our app started with CoreStore v1.4.4 I figured I could lean on the `defaultFileURL`, like so: ```swift try dataStack.addStorageAndWait( SQLiteStore( fileURL: LegacySQLiteStore.defaultFileURL, localStorageOptions: .allowSynchronousLightweightMigration ) } ``` However [the property is marked `internal`](https://github.com/JohnEstropia/CoreStore/blob/develop/Sources/Setup/StorageInterfaces/LegacySQLiteStore.swift#L249). I'd rather not have to duplicate that logic, could this access restriction be relaxed to allow the above? Or is there a better way to do what I'm trying to achieve. Also, is the only difference between `LegacySQLiteStore` and `SQLiteStore` the location of the data store file? Should I be updating my app away from `LegacySQLiteStore`? Thanks.

adam added the question label 2025-12-29 15:25:13 +01:00

adam closed this issue

2025-12-29 15:25:13 +01:00

adam commented

2025-12-29 15:25:13 +01:00

@JohnEstropia commented on GitHub (Apr 13, 2017):

LegacySQLiteStore and SQLiteStore are just lightweight descriptors. You can simply create an instance to extract the default URL:

try dataStack.addStorageAndWait(
    SQLiteStore(
        fileURL: LegacySQLiteStore().fileURL,
        localStorageOptions: .allowSynchronousLightweightMigration
    )
}

Also, is the only difference between LegacySQLiteStore and SQLiteStore the location of the data store file?

Yes. The SQLiteStore's default path conforms better to standard iOS and macOS recommended directory naming
Specifically:

Application Support:
... 
All content in this directory should be placed in a custom subdirectory whose name is that of your app’s bundle identifier or your company.

Should I be updating my app away from LegacySQLiteStore?

If you are supporting migrations, you need to make sure that your future code will result in the exact same URL as your app's old versions. Wether you use LegacySQLiteStore or SQLiteStore, I recommend letting your app explicitly provide the file path. You are not "duplicating logic" here, you are ensuring your users can still migrate even if CoreStore changes it's default directories in the future.
(Of course I won't make updates like that, but it's safer to be vigilant)

With regards to file paths, LegacySQLiteStore and SQLiteStore will be maintained with considerations to protect past app installs, but future new features will generally be directed towards SQLiteStore.

@JohnEstropia commented on GitHub (Apr 13, 2017): `LegacySQLiteStore` and `SQLiteStore` are just lightweight descriptors. You can simply create an instance to extract the default URL: ```swift try dataStack.addStorageAndWait( SQLiteStore( fileURL: LegacySQLiteStore().fileURL, localStorageOptions: .allowSynchronousLightweightMigration ) } ``` > Also, is the only difference between LegacySQLiteStore and SQLiteStore the location of the data store file? Yes. The SQLiteStore's default path conforms better to standard [iOS and macOS recommended directory naming](https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1) Specifically: ``` Application Support: ... All content in this directory should be placed in a custom subdirectory whose name is that of your app’s bundle identifier or your company. ``` > Should I be updating my app away from LegacySQLiteStore? If you are supporting migrations, you need to make sure that your future code will result in the exact same URL as your app's old versions. Wether you use `LegacySQLiteStore` or `SQLiteStore`, I recommend letting your app explicitly provide the file path. You are not "duplicating logic" here, you are ensuring your users can still migrate even if CoreStore changes it's default directories in the future. (Of course I won't make updates like that, but it's safer to be vigilant) With regards to file paths, `LegacySQLiteStore` and `SQLiteStore` will be maintained with considerations to protect past app installs, but future new features will generally be directed towards `SQLiteStore`.

adam commented

2025-12-29 15:25:14 +01:00

@jamesbebbington commented on GitHub (Apr 24, 2017):

Thanks @JohnEstropia, that all makes sense.

@jamesbebbington commented on GitHub (Apr 24, 2017): Thanks @JohnEstropia, that all makes sense.

adam commented

2025-12-29 15:25:14 +01:00

@jamesbebbington commented on GitHub (Apr 26, 2017):

Hey @JohnEstropia actually, looking back through our project history, we started off with CoreStore v1.4.4 but upgraded to v2.0.6 before our first public release of the app.

So all our users should have their DBs stored at the new SQLiteStore.defaultFileURL and I can ignore all this LegacySQLiteStore business right?

@jamesbebbington commented on GitHub (Apr 26, 2017): Hey @JohnEstropia actually, looking back through our project history, we started off with CoreStore v1.4.4 but upgraded to v2.0.6 before our first public release of the app. So all our users should have their DBs stored at the new `SQLiteStore.defaultFileURL` and I can ignore all this `LegacySQLiteStore` business right?

adam commented

2025-12-29 15:25:14 +01:00

@JohnEstropia commented on GitHub (Apr 27, 2017):

Since CoreStore 2.0 CoreStore.addStorageAndWait() internally uses SQLiteStore, so yes I think you are all set :)

@JohnEstropia commented on GitHub (Apr 27, 2017): Since CoreStore 2.0 `CoreStore.addStorageAndWait()` internally uses SQLiteStore, so yes I think you are all set :)

adam commented

2025-12-29 15:25:15 +01:00

@JohnEstropia commented on GitHub (Apr 27, 2017):

One advise: you can always test migration by installing your app's old version and then running your latest app.

@JohnEstropia commented on GitHub (Apr 27, 2017): One advise: you can always test migration by installing your app's old version and then running your latest app.

Sign in to join this conversation.

Branches Tags

develop

master

prototype/concurrency

minIOS13

prototype/containers

transactionSourceTracking

prototype/swiftui

minIOS11

swift5_3

prototype/propertyWrapperFields

prototype/propertyWrappers

prototype/propertyWrapper

Swift5

throwables

prototype/Swift_4_1

prototype/Swift_4_0

prototype/Swift_3_2

prototype/queryBuilders

temp/develop

corestore4_develop

prototype/mainContextToPSC

master_ios_7_to_9

swift_2_3

gh-pages

_corespotlight-test

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/CoreStore#132