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.
Coverage compiler and linker flags are used only when (1) in debug build
and (2) with ENABLE_COVERAGE set to 1. Besides, because OS X's libtool
is unable to understand '--coverage', this linker flag is only used
genrating executable targets. Also, using 'link_settings' to specify
linker options and separate instructions for OSX and Linux.
These tests are intended to reflect how someone using the custom layer feature might actually write their callbacks. Therefore the callbacks should not use mbgl-specific classes.
This reverts commit 69112a2a09.
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".
There is no such thing as a cancelled response, only cancelled requests. A request that is cancelled does not have its callback called with a Response.
Implicit bool conversions are bad; they'll be used e.g. for a == b and a != b if those operators are not defined. This was happening at 032c8fba3c/src/mbgl/map/transform.cpp (L132-L132), for example.
* Use "named constructors": empty, world, hull
* Make the two-argument constructor lenient (i.e., it is a hull operation)
* Add various accessors
* Enforce a single empty representation
Now it works more like StubStyleObserver: you can assign std::functions to specific slots based on resource type.
Rewrite resource loading tests in that style, making them less like integration tests of Style and more like unit tests of Source, GlyphStore, and SpriteStore.
