SQLiteStore.defaultFileURL access restriction #132

New Issue

Closed

opened 2025-12-29 15:25:13 +01:00 by adam · 5 comments

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

Owner

Copy Link

Copy Source

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

Author

Owner

Copy Link

Copy Source

@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

Author

Owner

Copy Link

Copy Source

@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

Author

Owner

Copy Link

Copy Source

@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

Author

Owner

Copy Link

Copy Source

@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

Author

Owner

Copy Link

Copy Source

@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.

No Branch/Tag Specified

Branches Tags

develop

prototype/swift6

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

9.3.0

9.2.0

9.1.0

9.0.0

8.1.0

8.0.1

8.0.0

7.3.1

7.3.0

7.2.0

7.1.0

7.0.4

7.0.3

7.0.2

7.0.1

7.0.0

6.3.2

6.3.1

6.3.0

6.2.1

6.2.0

6.1.0

6.0.0

5.3.1

5.3.0

5.2.0

5.1.1

5.1.0

5.0.0

4.2.4

4.2.3

4.2.2

4.2.1

4.2.0

4.1.4

4.1.3

4.1.1

4.1.0

4.0.5

4.0.4

4.0.3

4.0.2

4.0.1

4.0.0

4.0.0-beta3

4.0.0-beta2

4.0.0-beta

3.1.1

3.1.0

3.0.3

3.0.2

3.0.1

3.0.0

2.1.3

2.1.2

2.1.1

2.1.0

2.0.6

2.0.5

2.0.4

2.0.3

2.0.2

2.0.1

2.0.0

1.6.10

1.6.9

1.6.8

1.6.7

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.1

1.2.0

1.0.2

1.0.1

1.0.0

0.2.1

0.2.0

0.1.2

0.1.1

0.1.0

Labels

Clear labels

abandoned

corestore bug

discussion

duplicate

enhancement

fixed

fixed

help wanted

in progress

investigating

ios/compiler bug

irreproducible

looking for workarounds

not a bug

pending

pending docs update

pull-request

Mirrored from GitHub Pull Request

question

regression

user bug

wontfix

No labels question

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

adam (Adam Melkus)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/CoreStore#132