* [core] Quadkey tokens in tile URL templates
Fixes#5485.
* [core] WMS tokens in tile URL templates
Fixes#822.
* [macos] Added WMS debug style
Added a style to the macosapp resource bundle that can be used to test WMS support. To use it, zoom in to somewhere in New Jersey, then go to View ‣ Custom Style and enter “wms.json”.
Introduces "optional" requests. These should be fulfilled by the FileSource only there's a low-cost/easy way to obtain the data (e.g. from a local cache). If the data for an optional request cannot be found, it *must* return a Response object with a NotFound error.
Traditional "required" requests still work the same way, with one change: If you set any prior* field in the Resource (i.e. priorModified, priorEtag, or priorExpires), the DefaultFileSource assumes that you already have the cache value and will not consult the cache before performing the request. If a prior cache lookup didn't turn up any data, and you therefore don't have an Etag or Modified value, you can still skip the cache by setting priorExpires. This will of course always result in a non-conditional HTTP request.
* Main gyp files are now standardized as platform/<platform>/platform.gyp.
* Each platform gyp file defines appropriate loop_lib and headless_lib variables.
* Each platform gyp file includes mbgl.gypi, which defines base targets which may be useful to all platforms.
* CI targets are consistent across platforms: `make $(PLATFORM) && make test-$(PLATFORM)`.
* Renamed the "linux" test app to "glfw". It's now built in OS X CI.
* Android build flakiness is fixed.
* iOS CI builds the bench and iosapp targets.
* Mesa version is now in one place.
* CI scripts use bash "strict mode" and correct error handling.
* All build output goes to the build directory.
* Removed vestigial iOS/OS X/Android Travis scripts.
The migration was upgrading the schema, but not the schema version. As a result, the (expensive) migration was running every time an OfflineDatabase was constructed with a v2 database.
Fixes#4501
The tile limit guard (when used) stops a download from continuing
when the tile limit is reached. This wraps the guard in a method
and employs it in both places currently necessary to ensure the
guard has a chance to function. Tests have been updated to
ensure the fix works for a less trivial tile limit scenario.
The core of the change is ensuring that ensureResource doesn't release Zalgo: it should be consistently async, rather than async in the case that the resource doesn't exist in the database, but sync if it does.
This ensures that status is reported in a more consistent sequence, regardless of the database state.
SQLite REPLACE is *not* UPSERT. If a conflict occurs, it first deletes the existing row, then inserts a new row. This means that AUTOINCREMENT primary keys change. This will break foreign keys to that value, which we use.
Instead we must try an UPDATE, and fall back to an INSERT if the UPDATE changes zero rows.
error: converting ‘false’ to pointer type for argument 1 of ‘char
testing::internal::IsNullLiteralHelper(testing::internal::Secret*)’
[-Werror=conversion-null]
* Under the hood, SQLite creates surrogate keys (ROWID) anyway. We may as well take advantage of this and use the surrogates for foreign keys as well, since they are simpler and more efficient than compound foreign keys.
* Create indexes for efficient eviction queries
When inserting an cached resource, or removing a region, remove least-recently used resources and tiles, not used by offline regions, until the used database size, as calculated by multiplying the number of in-use pages by the page size, is less than the maximum cache size minus 5 times the page size.
In addition, OfflineDatabase may be configured to ignore cache puts of individual resources larger than a certain size.
This policy is similar but not identical to the former SQLiteCache policy:
* It accounts for offline, by exempting resources required by offline regions from eviction.
* It must delete from two tables (resources and tiles), rather than one. Currently the strategy is naive: evict 50 rows at a time from each table.
* It makes maximumCacheSize and maximumCacheEntrySize completely independent. The SQLiteCache implementation evicted when `usedSize > maximumCacheSize - 2 * maximumCacheEntrySize`. This evicts when `usedSize > maximumCacheSize - 5 * pageSize`.
* It uses a non-unlimited default value for maximumCacheSize: 50 MB. We should have always had a limit in place; "a cache without an eviction policy is a resource leak".
