Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New database table to track published (prod) file revisions #325

Open
mandolyte opened this issue Jun 23, 2021 · 3 comments
Open

New database table to track published (prod) file revisions #325

mandolyte opened this issue Jun 23, 2021 · 3 comments

Comments

@mandolyte
Copy link

The Gitea database (DCS uses MySql), will be updated to include a table which will be updated after a release to reflect any new revisions of the files. At present, the following columns are being considered for the “revision table”:

  • owner (ru_gl)
  • repo (ru_ta)
  • project id:
  • bookId for scripture resources (gen)
  • category-base_filename for TWs (names-aaron)
  • filename/pathname, examples:
  • TN: tn_TIT.tsv
  • TA: figs-apostrophe
  • TW: names/aaron.md
  • TWL: twl_TIT.tsv
  • revision
  • cut-in version (release where this revision was first introduced)
  • cut-in version iteration (if release was deleted and re-done, this counts them, 1, 2, 3, ... )
  • cut-off version (release where this revision was last present): empty if revision is still current
  • cut-off version iteration (similar to the cut-in iteration): empty if revision is still current
  • SHA value
  • SHA create timestamp
  • html_url
  • contents_url

This work package would include the code that runs at release time to maintain the above table. There are prerequisites that will be evaluated to determine if the release is considered “good enough”:

  • The repository must have a schema-valid manifest.
  • [under consideration] The repository files must pass content validation.
@richmahn
Copy link
Member

Just a note, a lot of these fields would be more likely in the API response object, where things like owner and repo (both names and objects) can be derived by a simple repo_id that then can be found in the repository table which has an owner_id which references the user table. html_url, content-url and such helpful API-specific properties be computed at the time that the database model object is converted to the API response object for each object.

@jdejoode
Copy link

jdejoode commented Jun 24, 2021

I am wondering how this would work for strictly offline use of our tools. If a teams does not want to use DCS, can they still access the type of information that this database is likely to store or are they limited in functionality?

@richmahn
Copy link
Member

richmahn commented Jul 8, 2021

@jdejoode Just have to run DCS on their own machine. Not hard. Can do it in a Docker container or compile the source, or use the https://github.com/unfoldingWord-dev/tx-dev-dcs repo to start one with populated data in a Docker container.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants