starred/CoreStore
1
0
Fork 0
mirror of https://github.com/JohnEstropia/CoreStore.git synced 2026-01-11 20:00:30 +01:00
Code Issues 95 Packages Projects Releases 10 Wiki Activity

Synchronous lightweight data migration #32

New Issue
Closed
opened 2025-12-29 15:22:40 +01:00 by adam · 3 comments
adam commented 2025-12-29 15:22:40 +01:00
Owner
Copy Link

Originally created by @plamenterziev on GitHub (Jan 21, 2016).

I am using addSQLiteStoreAndWait to setup my data stack. My model is very simple and the objects are with limited count (only 22) so any migration will work fast. However the current API I cannot perform lightweight migration and have to use the asynchronous addSQLiteStore method which will make my code more complex than needed.

An option to perform lightweight data migration even using the addSQLiteStoreAndWait method will be useful.

Originally created by @plamenterziev on GitHub (Jan 21, 2016). I am using addSQLiteStoreAndWait to setup my data stack. My model is very simple and the objects are with limited count (only 22) so any migration will work fast. However the current API I cannot perform lightweight migration and have to use the asynchronous addSQLiteStore method which will make my code more complex than needed. An option to perform lightweight data migration even using the addSQLiteStoreAndWait method will be useful.
adam added the wontfix label 2025-12-29 15:22:40 +01:00
adam closed this issue 2025-12-29 15:22:40 +01:00
adam commented 2025-12-29 15:22:41 +01:00
Author
Owner
Copy Link

@JohnEstropia commented on GitHub (Jan 21, 2016):

@plamenterziev Thanks for the feedback!
I understand the convenience of having a synchronous migration method, but I find little merit to writing a separate API for it for several reasons:

  1. No matter how small your data store is, CoreStore still implements incremental migrations. Multiple synchronous migrations run consecutive to each other will be very prone to deadlocks.
  2. In my opinion, the benefits of rewriting an app's launch code to support asynchronous startup far outweighs the cost of maintaining a synchronous API that is not very safe to begin with.
  3. I believe there are far more apps that need the asynchronous version, and I don't want to encourage use of the synchronous API.

Sorry, I don't think there's enough good reasons to support this. I suggest you give your app a startup screen and then switch to your main view controller once addSQLiteStore's completion runs.

@JohnEstropia commented on GitHub (Jan 21, 2016): @plamenterziev Thanks for the feedback! I understand the convenience of having a synchronous migration method, but I find little merit to writing a separate API for it for several reasons: 1. No matter how small your data store is, CoreStore still implements incremental migrations. Multiple synchronous migrations run consecutive to each other will be very prone to deadlocks. 2. In my opinion, the benefits of rewriting an app's launch code to support asynchronous startup far outweighs the cost of maintaining a synchronous API that is not very safe to begin with. 3. I believe there are far more apps that need the asynchronous version, and I don't want to encourage use of the synchronous API. Sorry, I don't think there's enough good reasons to support this. I suggest you give your app a startup screen and then switch to your main view controller once addSQLiteStore's completion runs.
adam commented 2025-12-29 15:22:41 +01:00
Author
Owner
Copy Link

@plamenterziev commented on GitHub (Jan 22, 2016):

Hi @JohnEstropia

I understand your point, so what about the following:

Just allow user to be able to supply options when opening the persistent store, i.e. to provide custom options in optionsForSQLiteStore() dictionary?

@plamenterziev commented on GitHub (Jan 22, 2016): Hi @JohnEstropia I understand your point, so what about the following: Just allow user to be able to supply options when opening the persistent store, i.e. to provide custom options in optionsForSQLiteStore() dictionary?
adam commented 2025-12-29 15:22:41 +01:00
Author
Owner
Copy Link

@JohnEstropia commented on GitHub (Jan 26, 2016):

@plamenterziev
Hi, sorry for the late reply.

I'm sorry but I'm not fond of supporting API's that I won't encourage using. Adding a synchronous method that provide the option for migration provides more risk than the simplicity it provides.

Of course you are free to fork CoreStore and implement your method :)

@JohnEstropia commented on GitHub (Jan 26, 2016): @plamenterziev Hi, sorry for the late reply. I'm sorry but I'm not fond of supporting API's that I won't encourage using. Adding a synchronous method that provide the option for migration provides more risk than the simplicity it provides. Of course you are free to fork CoreStore and implement your method :)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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 Label wontfix
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/CoreStore#32
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?