-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[core][android] Introduce OfflineManager.runPackDatabaseAutomatically(boolean) API #15967
Conversation
565ab6a
to
753a640
Compare
@pozdnyakov @tmpsantos thanks for this -- I like the idea a lot! Right now I'm wondering whether the naming and documentation of these APIs could be further clarified. I think one way we could add greater clarity is by explicitly referencing the SQLite
|
@@ -669,6 +669,23 @@ private boolean isValidOfflineRegionDefinition(OfflineRegionDefinition definitio | |||
@Keep | |||
public native void setOfflineMapboxTileCountLimit(long limit); | |||
|
|||
/** | |||
* Sets the automatic database file packing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, when we're ready to merge, changes to platform files should be PRed separately in https://github.com/mapbox/mapbox-gl-native-android
This will be required after #15970 lands
@@ -195,6 +190,11 @@ class DefaultFileSource : public FileSource { | |||
*/ | |||
void packDatabase(std::function<void(std::exception_ptr)> callback); | |||
|
|||
/* | |||
* Enables or disables auto database file packing after deleteing regions and clearing ambient cache. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion:
Sets whether packing the database by invoking VACUUM on SQLite occurs automatically after an offline region is deleted (
deleteOfflineRegion()
) or the ambient cache is cleared (clearAmbientCache()
).
By default, packing is enabled. If disabled, disk space will not be freed after resources are removed unless
packDatabase()
is explicitly called.
/* | ||
* Enables or disables auto database file packing after deleteing regions and clearing ambient cache. | ||
*/ | ||
void setAutopack(bool); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this API name is confusing. Naming this function void runPackDatabaseAutomatically(bool)
would be a little clearer: the full reference to the related API is provided and it's obvious that if true
, packDatabase
is run.
But why not implement this functionality so that boolean runPackDatabase
is accepted as a variable in existing functions? e.g.:
void deleteOfflineRegion(OfflineRegion&&, std::function<void(std::exception_ptr)>, bool runPackDatabase = true);
void clearAmbientCache(std::function<void (std::exception_ptr)>, bool runPackDatabase = true);
This way, the developer can decide with each function call whether to run packDatabase()
automatically, and this new "setAutopack"
API is not needed.
My understanding is that this wouldn't be a breaking change because if runPackDatabase
is not passed in by the developer, it defaults to true which matches current behavior of both APIs.
In the future, my preference would be to name all APIs around VACUUM/database defragmentation with those words explicitly.
Unless packDatabase()
does something additional to running VACUUM
, what value do we provide the developer by wrapping a widely-known functionality (https://www.sqlitetutorial.net/sqlite-vacuum/) around this ambiguous word "pack"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless packDatabase() does something additional to running VACUUM, what value do we provide the developer by wrapping a widely-known functionality (https://www.sqlitetutorial.net/sqlite-vacuum/) around this ambiguous word "pack"?
VACUUM
is tied to sqlite, at some point we can switch to another DB provider. IMO it's better to keep API generic enough.
But why not implement this functionality so that boolean runPackDatabase is accepted as a variable in existing functions?
This does not match well with the Android API: java does not support method parameters set by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, we do not run VACUUM
- we run PRAGMA incremental_vacuum
which provides a different behavior, so we'd better not to disclose the implementation internals in the API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
VACUUM is tied to sqlite, at some point we can switch to another DB provider. IMO it's better to keep API generic enough.
Also, we do not run VACUUM - we run PRAGMA incremental_vacuum which provides a different behavior, so we'd better not to disclose the implementation internals in the API.
Gotcha, makes sense to not reference VACUUM in the API name. Still, I think perhaps an alternative to "pack" should be considered for the future, unless there's a great reason why "pack" makes sense that I'm overlooking.
@pozdnyakov what do you think about specifying VACUUM / PRAGMA incremental_vacuum in the inline documentation though?
This does not match well with the Android API: java does not support method parameters set by default.
😔 I guess our hands are tied here.
@pozdnyakov what do you think about changing the name from setAutopack
to runPackDatabaseAutomatically
then? (Also open to other suggestions.)
Finally -- is this function a global function for OfflineManager
, so that if set, it would apply to every call to deleteOfflineRegion
or clearAmbientCache
that happens afterwards?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pozdnyakov what do you think about specifying VACUUM / PRAGMA incremental_vacuum in the inline documentation though?
We could mention it as possible implementation detail, however, it's better IMO to just describe what it does - shrink the database file size, and point out the potential performance issues.
@pozdnyakov what do you think about changing the name from setAutopack to runPackDatabaseAutomatically then? (Also open to other suggestions.)
runPackDatabaseAutomatically
looks much better, thanks for proposing it!
Finally -- is this function a global function for OfflineManager, so that if set, it would apply to every call to deleteOfflineRegion or clearAmbientCache that happens afterwards?
yeah, it'll apply to all the following calls of deleteOfflineRegion or clearAmbientCache.
...orm/android/MapboxGLAndroidSDK/src/main/java/com/mapbox/mapboxsdk/offline/OfflineRegion.java
Show resolved
Hide resolved
This reverts commit 9bc3aa4.
- added a unit test - Updated inline comments in default_file_source.hpp
753a640
to
ada01e0
Compare
@chloekraw Thanks for your comments! They are considered in the latest patch set. |
@@ -705,7 +705,7 @@ std::exception_ptr OfflineDatabase::clearAmbientCache() try { | |||
|
|||
resourceQuery.run(); | |||
|
|||
vacuum(); | |||
if (autopack) vacuum(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Optional: We could replace all the vacuum()
calls with a protected mayPack()
doing the autopack == true
check and move the code inside ::vacuum
to ::pack
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've places where vacuum should be called unconditionally, e.g. at database creation in order to enable incremental vacuum
Note for the change log: Introduce |
I will run point on integrating these changes in mapbox-gl-native-android |
Fixes mapbox/mapbox-gl-native-team#102