3 ms·

Have you checked the Apple apps? Most of them use SQLite as storage format. iMovie, iPhoto, Voice recording… Same with Docker. Can’t be that wrong?

tuyiown 3y ago
App using a format specific to their own and unique implementation, that ends up kind of proprietary is perfectly ok. Using it for a open specification which target is cross implementation compatibility makes the move way more hazardous. Meaning, every implementation has to run on environment targetable and compatible wit sqlite or has to re-implement a compatibility layer on something complex enough that you only reliable definitive source of truth is the very famous sqlite test suite. It the same reason why Web SQL has being abandoned: if sqlite is the sole api implementor, it takes precedence on any others specs, and you have no control on your standard. I would be 100% for a specification on how to map open docs files to an relational structure, though, with a well know sqlite-backed implementation.
- bawolff 3y ago
  > Meaning, every implementation has to run on environment targetable and compatible wit sqlite Well i get what you are saying, sqlite has been ported all over the place. It probably wouldn't be the limiting factor portability wise.
  - tuyiown 3y ago
    Yes, right now, no problem, and there little foreseeable future where a sqlite ported to anything would pose a problem. Still, decisions with no way back like this one requires extra cautions.
JimDabell 3y ago
The Apple apps are using Core Data, which uses SQLite as its persistent store by default. So Apple could in theory migrate away from SQLite by changing Core Data’s behaviour without any application-level impact. So in a way, these applications are already decoupled from SQLite in the way the parent comment suggests.

3 ms·

Have you checked the Apple apps? Most of them use SQLite as storage format. iMovie, iPhoto, Voice recording… Same with Docker. Can’t be that wrong?

by punnerud 3y ago

tuyiown 3y ago
App using a format specific to their own and unique implementation, that ends up kind of proprietary is perfectly ok. Using it for a open specification which target is cross implementation compatibility makes the move way more hazardous. Meaning, every implementation has to run on environment targetable and compatible wit sqlite or has to re-implement a compatibility layer on something complex enough that you only reliable definitive source of truth is the very famous sqlite test suite. It the same reason why Web SQL has being abandoned: if sqlite is the sole api implementor, it takes precedence on any others specs, and you have no control on your standard. I would be 100% for a specification on how to map open docs files to an relational structure, though, with a well know sqlite-backed implementation.
- bawolff 3y ago
  > Meaning, every implementation has to run on environment targetable and compatible wit sqlite Well i get what you are saying, sqlite has been ported all over the place. It probably wouldn't be the limiting factor portability wise.
  - tuyiown 3y ago
    Yes, right now, no problem, and there little foreseeable future where a sqlite ported to anything would pose a problem. Still, decisions with no way back like this one requires extra cautions.
JimDabell 3y ago
The Apple apps are using Core Data, which uses SQLite as its persistent store by default. So Apple could in theory migrate away from SQLite by changing Core Data’s behaviour without any application-level impact. So in a way, these applications are already decoupled from SQLite in the way the parent comment suggests.