Unable to get a reliable way to sort by "created" in the core implementation without adding access to logbook for the core Collection. We would also need to add a Created field to VersionInfo. If/when we create a UberData struct, this field should be moved there.
Initially, I thought we could rely on the natural ordering of the collection, and assume that each dataset is added to the collection in the order it was created. However, this does not hold for datasets that you pull from a remote, as these can be created at any time & pulled at any later time. However, once we pull a dataset, we have access to it's history & can determine the time of creation via the logbook, hence the need to for the core implementation to access logbook to determine the "created" time.
Further:
We need to enforce a more detailed & standard way to sort lists in qri core & to merge some of our different "list params". However, I think we should wait for the cursor work to land before implementing changes.
depends on #1980
closes #1974
NOTES:
Unable to get a reliable way to sort by "created" in the core implementation without adding access to
logbookfor the coreCollection. We would also need to add aCreatedfield toVersionInfo. If/when we create aUberDatastruct, this field should be moved there.Initially, I thought we could rely on the natural ordering of the collection, and assume that each dataset is added to the collection in the order it was created. However, this does not hold for datasets that you pull from a remote, as these can be created at any time & pulled at any later time. However, once we pull a dataset, we have access to it's history & can determine the time of creation via the
logbook, hence the need to for the core implementation to accesslogbookto determine the "created" time.Further: We need to enforce a more detailed & standard way to sort lists in qri core & to merge some of our different "list params". However, I think we should wait for the
cursorwork to land before implementing changes.