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

[Server support] - Update collection-listing strategy from client filesystem #139

Open
1 of 2 tasks
Tracked by #136
matuella opened this issue Jul 19, 2021 · 2 comments
Open
1 of 2 tasks
Tracked by #136
Assignees
Labels
enhancement New feature or changes to an existing one P1 Changes that should be worked now target: collections Relates to collections, or any of its memos target: firebase Relates to Firebase and its sub-dependencies

Comments

@matuella
Copy link
Contributor

matuella commented Jul 19, 2021

This issue should solve adding new collections using only Firebase, thus allowing much more flexibility to the client applications when receiving new collection updates.

What it should do, technically speaking, is:

  • move all collections from flutter/ to firebase/;
  • then, with the admin SDK capabilities, every time an update occurs (in main branch) within this new folder of collections, run a script (using Github Actions, through a new workflow) to evaluate such changes, compare this new state to what's stored in the production firestore, and make the required writes to mirror this new state.

This is similar to what's occurring locally in VersionServices, although there is an additional complexity of handling both global and user collections - meaning that removing/updating past existing user collections should be made with extra care, as to not create any inconsistency.


Sub-issue that relates to the Server support - #136.

@matuella matuella added new feature target: firebase Relates to Firebase and its sub-dependencies labels Jul 19, 2021
@matuella matuella added enhancement New feature or changes to an existing one P1 Changes that should be worked now and removed new feature labels Sep 2, 2021
@matuella
Copy link
Contributor Author

then, with the admin SDK capabilities, every time an update occurs (in main branch) within this new folder of collections, run a script (using Github Actions, through a new workflow) to evaluate such changes, compare this new state to what's stored in the production firestore, and make the required writes to mirror this new state.

Maybe there is a way for the action to pass the specific collections that changed when a push to main and has passed the conditional filters.

The syntax to filter are called paths (https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#onpushpull_requestpaths) but I'm not sure if we are able to collect the file names that changed in a particular sub-folder.

@matuella matuella self-assigned this Sep 29, 2021
@matuella matuella added the target: collections Relates to collections, or any of its memos label Sep 29, 2021
@matuella
Copy link
Contributor Author

matuella commented Oct 1, 2021

but I'm not sure if we are able to collect the file names that changed in a particular sub-folder.

I've found a couple of alternatives if there is no default way to get these:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or changes to an existing one P1 Changes that should be worked now target: collections Relates to collections, or any of its memos target: firebase Relates to Firebase and its sub-dependencies
Projects
None yet
Development

No branches or pull requests

2 participants