Mongo 4: Client changes to support revisions#1070
Conversation
waxlamp
modified the milestones:
Annotations in MongoDB,
Sprint November 30 - December 14
waxlamp
modified the milestones:
Sprint November 30 - December 14,
Sprint December 14 - December 28
subdavis
force-pushed
the
mongo/unit-integration-tests
branch
from
a412b6c to
2b20dc3
Compare
subdavis
force-pushed
the
mongo/unit-integration-tests
branch
from
2b20dc3 to
9b37323
Compare
subdavis
changed the title
subdavis
changed the base branch from
mongo/unit-integration-tests
to
mongo/celery-updates
subdavis
force-pushed
the
mongo/client-changes
branch
from
59f3f4d to
95b01b8
Compare
subdavis
force-pushed
the
mongo/client-changes
branch
from
50595bf to
867c74f
Compare
subdavis
force-pushed
the
develop-mongo-tracks
branch
from
4baea43 to
1082ca6
Compare
subdavis
force-pushed
the
mongo/client-changes
branch
from
867c74f to
72a8ed0
Compare
|
I don't know if this is a thing that needs to be solved by this PR. But the act of importing/running a pipeline on an earlier revision really runs on the latest revision instead. Like doing box to polygon conversion on an earlier revision will use the annotations from the latest revision. I don't know if the proper behavior is to prevent import/pipelines on earlier revisions that would modify the data or make it so pipelines use the proper revision number as input. |
|
@BryonLewis thanks for raising that issue. This is currently a hidden feature: there's no way to get to an earlier revision without typing it out, so I'm not worried about users stumbling upon it. revision ID inputs will indeed need to be added in several more places, but I think that's out of scope for a little while until we can figure out how to sanely let users access/review their previous revisions. LMK if you're OK with that. |
|
For starters, I think the "previous revision" view will need to totally disable all controls. No editing, no save, no training or pipelines. |
BryonLewis
left a comment
BryonLewis
left a comment
There was a problem hiding this comment.
I have a minor thing with a possible undefined making it into the :key for a component. It should function but probably not the best thing. Other than that the revision stuff I believe worked as intended.
| <Viewer | ||
| :id="id" | ||
| :key="id" | ||
| :key="`${id}/${revisionNum}`" |
There was a problem hiding this comment.
I think this is minor. But if revisionNum === undefined the key may seem weird but it should still work (All undefined keys should be the same revision anyways in terms of vDOM)
There was a problem hiding this comment.
It's just a hashable string, so it works fine like this. What would you like to change it to?
There was a problem hiding this comment.
leave it, I guess if it doesn't cause issues it's fine.
* Mongo 1: Server side implementation (#1066) * Poetry fix (#1087) * Poetry fix * Add check for app root * Desktop/sealion multicam (#1024) * init * Allowing multicam to write tracks * inut name change * lint fixes * Updates to multicam * fixing import loading * removing multicamImageFiles change * Fixing various issues * mend * mend * switching to every * Example without fetching metadata (#1088) Co-authored-by: Brandon Davis <brandon.davis@kitware.com> * Server-side implementation * Include description and timestamp * Respond to comments * Switch to checking mongo results * select sub-element * Unmangle indices Co-authored-by: BryonLewis <61746913+BryonLewis@users.noreply.github.com> * Mongo 2: Rollback API (#1067) * Implement rollback * Switch to POST /dive_annotation/rollback * Mongo 3: Utilize new endpoints in celery (#1068) * Utilize new endpoints in celery * Respond to comments * Linting, formatting, and unit tests * respond to comments * Import shutil * Client changes to support revisions (#1070) * Remove broken summary and report generation (#1071) * Add simple sharing test and new indices * Migraction script updates * Add loading state to clone button * label fetch Co-authored-by: BryonLewis <61746913+BryonLewis@users.noreply.github.com>
3 participants
Adds optional
viewer/:datasetId/rev/:revisionIdto route which loads the dataset from a specified revision. Whenever this optional route param is used, the UI is placed into the already implementated "read-only" state.I think the UI needs more clear indication that a previous revision is loaded, what that means, and how to either commit the rollback or return to HEAD, but that seemed out of scope until the rest of the revision history is implemented. For now, this is more of an easter-egg feature for us.