Our prototype integrations currently fail to open databases with older
schema versions. Let's throw away and replace these databases
instead of failing.
The `rs` module contains crate-internal types related to Remote
Settings. Since `SuggestionProvider` is part of the public interface,
and has non-trivial methods, let's give it its own module.
This commit:
* Renames some of our crate-internal types and methods to clarify that
they're specific to AMP-Wikipedia suggestions.
* Generalizes `DownloadedSuggestDataAttachment` to a `SuggestAttachment`
type that can accommodate any suggestion.
* Removes `icon_id` from the common `suggestions` table, because not
all suggestions that we'll support in the future have icon data. For
example, Pocket suggestions don't have icons at all, and AMO
suggestions have URLs instead of binary data.
We'll want to handle these eventually, as part of a bigger rework for
unknown records and suggestion fields in DISCO-2564. For now, though,
let's at least advance the last sync time when we see them, to be
consistent with how we handle other records.
This commit refactors the Suggest component to use the Remote Settings
conveniences added in the last three commits.
* `get_records_with_options` replaces `get_records_raw_with_options`.
As part of this change, Suggest now uses the `RemoteSettingsResponse`
and `RemoteSettingsRecord` types from the Remote Settings component,
instead of defining its own types and deserializing them from the
Viaduct response.
* `SuggestRemoteSettingsClient` becomes a thin wrapper around the Remote
Settings client, and calls its methods directly. This helps keep the
mocking surface small.
Instead of setting up a mock Remote Settings HTTP server in each test,
we can use a trait to abstract over the Remote Settings client, and use
different implementations in production and test code. This will make it
much easier to write our unit tests.
This commit:
* Implements the `SuggestRemoteSettingsClient` trait for the
production client (`remote_settings::Client`).
* Factors out the `SuggestStore` implementation into an inner
`SuggestStoreInner` type that's generic over the Remote Settings
client.
* Refactors the public `SuggestStore` type to delegate to a concrete
instance of the inner store for the production client
(`SuggestStoreInner<remote_settings::Client>`).
This commit renames:
* `RemoteSuggestion` to `DownloadedSuggestion` and
`SuggestDataAttachmentContents` to `DownloadedSuggestDataAttachment`,
for consistency with the "downloading" terminology.
* `RemoteRecordId` to `SuggestRecordId`, for consistency with the other
Remote Settings types.
"Fetching" is a bit of an overloaded term that can refer to querying
ingested suggestions, or downloading records from Remote Settings. To
reduce confusion, let's replace those uses with more precise
terminology:
* "Downloading" for when we request suggestions from Remote Settings.
* "Ingesting" for storing the downloaded suggestions in the database.
* "Querying" for when the application requests ingested suggestions.
This commit also generalizes `IngestLimits.records` to
`SuggestIngestionConstraints.max_suggestions`, since the partitioning
scheme and number of suggestions per Remote Settings attachment is an
implementation detail.
This commit makes it possible to combine multiple database accesses
into a single transaction. Previously, each `SuggestDb` method would
lock the database connection, and optionally run its own transaction
before releasing the lock. This meant that a single logical operation,
like ingesting all suggestions from an attachment, would involve
multiple transactions.
This commit moves the database accesses into a new `SuggestDao` type,
which takes a reference to an existing locked connection. The new
`SuggestDb::{read, write}` methods handle locking and transaction
management, and take a closure that receives a `SuggestDao` for reading
and writing.
Co-authored-by: Tif Tran <ttran@mozilla.com>
This commit changes the visibility of crate-internal types and methods
from `pub` to `pub(crate)`, and clarifies the difference between the two
error types:
* `SuggestApiError` is the public error type, for all errors that should
be handled by the application.
* `Error` is the internal error type, used in the implementation of the
component, and is not part of the public interface.
The Gecko JS UniFFI bindings don't support synchronous function calls
yet (https://bugzilla.mozilla.org/show_bug.cgi?id=1842433), so the
builder API will be a little awkward to use on Desktop.
This commit replaces the builder with a dictionary, with default
fields to make it more ergonomic.
In other uses, "provider" refers to the source of a suggestion, like
adM, Wikipedia, AMO, etc. Since `SuggestionProvider` aggregates
suggestions from all these sources, calling it a "provider" could be
confusing, especially if we support filtering suggestions from specific
sources in the future.
Before, creating a provider would block the calling thread until the
database was set up. Now, migrations will run the first time the
database is accessed, which we already expect to happen on a background
thread.
Lina Butler
Tif Tran