Closed xstephen95x closed 7 years ago
@slivingston Should we use HTTP, or firebase.database().ref().on() as an event listener?
would the HTTP request be sent from client-side?
if so, then there must be some server listening for connections from arbitrary hosts, which introduces security risks. Instead, I recommend the second approach that you sketch, i.e., using a queue from monitoring the Firebase database.
I also recommend the firebase stack idea. It works well for the artist portal.
All objects in the branch should be inserted in the curator SQL database.
This can be done with a script with a listener such as
firebase.database().ref("approved").on("child_added", (snapshot)=>{ do stuff });
After an artwork has been inserted, a field of imported
should be added to the object, and set to true
Alternatively, these can be removed from the DB, as the data is already present in the SQL DB.
from meeting on feb 18, it was concluded that both the artist daemon and curator daemon can be ran on the same GCE instance, using different tmux
sessions.
Moved into separate repo
Done in commit to curator-daemon.
Restructure:
The curator-tekuma firebase database should have 4 branches used in the review process.
submissions
,approved
,held
, andrejected
.Each branch is keyed by the artwork_uid of the image/artwork in question. The curator has authority to move data between each branch. Though, some moves should trigger external responses.
For any moves into the
approved
branch, the daemon should be triggered to (1) insert the data into the central SQL database and (2) add a field to the JSON in the approved branch to denote that it has been successfully inserted.For any moves into 'held' , the daemon should access the artist-tekuma firebase database, and change the
submitted
tag to allow for the artist to edit/revise their artwork.