The warnings are:
no edition set: defaulting to the 2015 edition while the latest is 2021
unused manifest key: lib.plugin
Differential Revision: https://phabricator.services.mozilla.com/D226855
Use `carray`` extension to bind array of numerics and strings, so we can
avoid large and slow IN clauses, and cache prepared statements having
a variable number of parameters.
The extension is statically loaded and available in every connection.
Consumers are encouraged to use the explicit `bindArrayXXX` methods, as
the generic `bindByIndex` and `bindByName` methods are too lenient,
especially from Javascript.
Note `carray`` only supports UTF8 encoded strings, the API will convert
the encoding when UTF16 is passed in.
These new variants are not exposed to Rust yet, as the existing comment
suggests they were intended for primitive types. It could be done in the
future, if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D225334
Use `carray`` extension to bind array of numerics and strings, so we can
avoid large and slow IN clauses, and cache prepared statements having
a variable number of parameters.
The extension is statically loaded and available in every connection.
Consumers are encouraged to use the explicit `bindArrayXXX` methods, as
the generic `bindByIndex` and `bindByName` methods are too lenient,
especially from Javascript.
Note `carray`` only supports UTF8 encoded strings, the API will convert
the encoding when UTF16 is passed in.
These new variants are not exposed to Rust yet, as the existing comment
suggests they were intended for primitive types. It could be done in the
future, if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D225334
`mParamsArray` doesn't need to be released on the main-thread as it doesn't
contain anymore instances of XPCVariant. The variants used are derived from
thread-safe Storage Variant_base.
Differential Revision: https://phabricator.services.mozilla.com/D220100
This also fixes a bug in the test_connection_online_backup.js test which wasn't
properly evaluating that the page_size PRAGMA was being copied properly.
Differential Revision: https://phabricator.services.mozilla.com/D207471
Sorry for the massive patch but I found it hard to split without
introducing a bunch of copies around...
This mostly makes necko and DOM agree on which strings to use, which
should result on less copies and conversions.
Differential Revision: https://phabricator.services.mozilla.com/D205601
This changes comes with several different refactorings all rolled into one,
unfotunately I couldn't find a way to pull them apart:
- First of all annotations now can either recorded (that is, we copy the value
and have the crash reporting code own the copy) or registered. Several
annotations are changed to use this functionality so that we don't need to
update them as their value change.
- The code in the exception handler is modified to read the annotations from
the mozannotation_client crate. This has the unfortunate side-effect that
we need three different bits of code to serialize them: one for annotations
read from a child process, one for reading annotations from the main process
outside of the exception handler and one for reading annotations from the
main process within the exception handler. As we move to fully
out-of-process crash reporting the last two methods will go away.
- The mozannotation_client crate now doesn't record annotation types anymore.
I realized as I was working on this that storing types at runtime has two
issues: the first one is that buggy code might change the type of an
annotation (that is record it under two different types at two different
moments), the second issue is that types might become corrupt during a
crash, so better enforce them at annotation-writing time. The end result is
that the mozannotation_* crates now only store byte buffers, track the
format the data is stored in (null-terminated string, fixed size buffer,
etc...) but not the type of data each annotation is supposed to contain.
- Which brings us to the next change: concrete types for annotations are now
enforced when they're written out. If an annotation doesn't match the
expected type it's skipped. Storing an annotation with the wrong type will
also trigger an assertion in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D195248
This utility copies an SQLite database, but does so just by performing a file
copy on the database itself. It assumes that there are no open connections on
the underlying database file.
Given that this is only used by Places, and that a later patch in this stack
adds a database backup utility that works even if there are open connections,
means we can move this old utility out form the mozIStorageService and into
a dedicated Places helper instead.
Differential Revision: https://phabricator.services.mozilla.com/D198309
The API can only load from a predetermined list of extensions statically built
in the same library as SQLite (either nss3 or mozsqlite3 at this time).
New extensions must be audited and their code updated through the update.sh
script.
All the extensions should be compilable and usable across all the tier1
platforms and from Rusqlite.
Differential Revision: https://phabricator.services.mozilla.com/D191316
Move SQLite updates to the `mach vendor` system to simplify updates.
This will have to be invoked manually through `./mach vendor`, as updatebot
is not hooked up yet (tracking new versions through Github tags is not reliable).
Build FTS5 statically in the same library as SQLite, but as a run-time
loadable extension.
Other extensions will similarly be added in the future, consumers can then use
mozStorage `loadExtension()` or Rusqlite `load_extension()` to load them.
FTS5 is used as a first example and for unit tests. While it could be enabled
statically, we prefer to have it on-demand and per connection.
Differential Revision: https://phabricator.services.mozilla.com/D191314
Move SQLite updates to the `mach vendor` system to simplify updates.
This will have to be invoked manually through `./mach vendor`, as updatebot
is not hooked up yet (tracking new versions through Github tags is not reliable).
Build FTS5 statically in the same library as SQLite, but as a run-time
loadable extension.
Other extensions will similarly be added in the future, consumers can then use
mozStorage `loadExtension()` or Rusqlite `load_extension()` to load them.
FTS5 is used as a first example and for unit tests. While it could be enabled
statically, we prefer to have it on-demand and per connection.
Differential Revision: https://phabricator.services.mozilla.com/D191314
The API can only load from a predetermined list of extensions statically built
in the same library as SQLite (either nss3 or mozsqlite3 at this time).
New extensions must be audited and their code updated through the update.sh
script.
All the extensions should be compilable and usable across all the tier1
platforms and from Rusqlite.
Differential Revision: https://phabricator.services.mozilla.com/D191316
Move SQLite updates to the `mach vendor` system to simplify updates.
This will have to be invoked manually through `./mach vendor`, as updatebot
is not hooked up yet (tracking new versions through Github tags is not reliable).
Build FTS5 statically in the same library as SQLite, but as a run-time
loadable extension.
Other extensions will similarly be added in the future, consumers can then use
mozStorage `loadExtension()` or Rusqlite `load_extension()` to load them.
FTS5 is used as a first example and for unit tests. While it could be enabled
statically, we prefer to have it on-demand and per connection.
Differential Revision: https://phabricator.services.mozilla.com/D191314
