feat: Versions API #38
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Intended for serving historical documents and loading data from Postgres or SQlite
- Introduce a `db` module responsible for managing database - Add `connect` function that's generic over SQLite and Postgres
Defaults to local SQLite database if `DATABASE_URL` is missing. After connecting, run any/all migrations that are necessary.
To manage migrations, it's first necessary to install `sqlx-cli`. - `cargo install sqlx-cli`. Then, `sqlx migrate add <name>` to add a new migration.
Adding new migrations won't trigger cargo recompilation, so sqlx strongly suggests we trigger a recompilation on new migrations.
After adding another field to the `AppState` struct the integration tests started failing. However, for the archive tests we don't really care about having database connection. To resolve, introduce a trait `GlobalState` that `init_app` implements and initializes the archive. This way we're flexibile in our testing framework and can use different structs to initialize the global app state.
This abstracts away the concrete database pool that's used by underlying sqlx. Trade-off is that we need the database-url to differentiate between databases
The purpose of the submodule is to store any/all functions that work with rdf. Currently the underlying implementation relies on `sophia` to parse the graph and retrieve triples. Add `namespaces.rs` module that stores rdf namespaces. Currently stores the `oll` and `dcterms` ontology. I expected the `dcterms` to be supported out-of-the-box, but `sophia` supports only the most frequently used namespaces.
…e authentication repo
Set a boolean revoked to True for publications that exist on same date. Revoked publications aren't accounted for when querying for versions for a publication.
Used for partially inserting changes by finding the last inserted pub, then the last inserted version
Re-use the existing insert function, as most of the code is the same. The only difference is that we skip parsing/loading publications which are already inserted in the db. For publication directories which aren't in the DB, we continue inserting changes.
- Introduce a `routing` module, intended as a central place to map all routing in stelae app. Introduced the `_api` scope with the versions endpoint - feat(api): initial versions endpoint - feat(app): call register_api routing function - feat(api): extract stele name from request
This commit introduces a new endpoint in stelae to get all the meaningful dates on which a document or a collection changed. Below is a summary of significant changes: - Add a new `api` module as a centralized place to look at all the endpoints stelae has. - refact: rename publish to app - feat(db): add Manager traits for model The reasoning being it's easier visually figure out which database queries work with which data structure. - feat(db): add version struct - feat(db): implement document and collection version queries Idea being we query for all the versions in which document or a collection changed. - feat(api): get all versions for a publication Executes the database query for document or library versions. - feat(api): map request/response body to structs Idea being it's more legibile to reason about the structure of the api. Rely on serde to serialize/deserialize values from and into json. - Introduce the `requests` and `response` modules for mapping the endpoint response to historical data for presentation - feat(api): support for historical messages In addition to the versions, we also display HTML messages that: i) show on which historical publication the user is currently on, ii) through which dates the currently viewed version was valid from (start and end date). If comparing versions, we show how many changes happened between the compare and version date.
- fix(api): assign Current value to variable after historical messages - refact: separate formatting logic into associated function `format_display_date` - lots of clippy lints
For the API, move the `versions.rs` into `versions/mod.rs`. The two modules for request and response are now in `request/mod.rs` and `response/mod.rs`. Historical messages are in the `response/messages.rs` module
These modules should make the code base more legibile. These changes include: - Moving `serve` current documents endpoint into `server/api/serve` module. This way we'll centralize all future endpoint logic in the `api` module - Centralize routing into `routes` mod. We'll expect to add new 'static' routing, while also keeping our dynamic logic in the same place. - Centralize global app state into `state` mod. - Small updates following the re-org of current codebase refact: rename structs in `state.rs` module to fix linting issues Address clippy lint warnings/pedantic errors related to generics in function arguments
|
I've made a new PR to isolate the commits #40 |
|
Closing in favor of #40 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #24
Introduce the /_api/versions endpoint. Idea being we query the database and, depending on the url request, return either all document or collection changes. The changes are mapped onto a
response::Versionsjson response.We'll need to update the insert changes logic again, so I vote to defer this and this issue at that point.
This pr builds on top of the pr already in review. So once merged, I'll update/rebase this PR to contain fewer commits.
@tombh only these 6 new commits are added: