search

dandi / dandi-archive

DANDI API server and Web app
https://dandiarchive.org
13 stars 13 forks source link

`Created` date for published versions is updated to the date of publishing #2075

Open kabilar opened 2 weeks ago

kabilar commented 2 weeks ago

Description

When a Dandiset has published versions the Created date on the DLP for a published version is updated to the date that the published version was created. For example, see Dandiset 000130 which is shown below.

Draft version image

Published version - January 12, 2022 image

Expected behavior

I would expect that the Created date should be the same for all published versions and the Draft version.

waxlamp commented 2 weeks ago

I would expect that the Created date should be the same for all published versions and the Draft version

Could you say more about why this is your expectation? I'll break this down into parts so I can ask some more focused questions. First, why would you expect the created date for "all published versions" to be the same? A published version is only created upon publishing the Dandiset, which means each published version should feature a created date matching the date it was published (e.g., the date that appears in the published version number).

Second, why would you expect the draft version's created date to change at all? Actually, I may know the answer to this one: are you thinking of the draft version of the Dandiset as something that becomes the published version, leading to the creation of a new draft version to work on? Our model differs from that: we consider the draft version to be a sort of permanent companion to the Dandiset; it is created when the Dandiset is created, and published versions are created independently "from" it. Under this model, the draft version is indeed created only once, then lives a long life spawning published versions, but never undergoing the sort of change that would necessitate new draft versions being created.

My other broad question is: what problems did this mismatch in expectations cause for you specifically? I want to figure that out because changing the model will have subtle effects that may cause bugs. We may be leaking implementation details into the interface in a way that is not helpful, but in that case, I'd want to explore alternative ways of displaying this date data in the DLP.

yarikoptic commented 2 weeks ago

I would expect that the Created date should be the same for all published versions and the Draft version.

me too. Whether published or draft, Created here should IMHO correspond to the time point of creation of the dandiset as a whole.

Moreover, as "published" version is published once and should never change, having both "Created" and "Modified" to correspond to the same date gives 0 extra bytes of information and thus questions rationale of having it there. While presenting the date when dandiset was created is exposing the life cycle of the dandiset (created X months ago, this version published Y months after).

The correct date is already present in the metadata which is associated with that dandiset:

❯ curl --silent -X 'GET' 'https://api.dandiarchive.org/api/dandisets/000130/versions/0.241017.1448/' -H 'accept: application/json' | jq .dateCreated
"2021-08-21T19:29:11.649012+00:00"

hence the fact that DLP uses some other date (when the "model" for that release was created... not really corresponding in semantics to "when dandiset was created") is just adding confusion to the user would would be finding correct date in the metadata.

Hence I think this is indeed a UX shortcoming and should be addressed.