Open
Description
Currently, the only way to get data about a specific version of a crate (or even just to know what is the latest version of a crate) is to query the Indexer
implementation.
But if an alternative Indexer
implementation relies on the network and needs to download entire crate version records every time we want to know what the latest version of a crate is, it could end up being quite slow and waste bandwidth.
So, we may duplicate version information in the database, which, I suspect, will almost always be faster to access and more efficient than the Indexer
implementation.
Here is the schema for how I could see it being shaped:
-- MySQL version (needs to be adjusted for other backends)
create table versions (
id bigint not null auto_increment unique primary key,
crate_id bigint not null,
num varchar(128) not null,
downloads bigint not null default 0,
created_at varchar(25) not null default concat(utc_date(), " ", utc_time()),
updated_at varchar(25) not null default concat(utc_date(), " ", utc_time()),
yanked bool not null default false,
published_by bigint unsigned not null,
foreign key (crate_id) references crates(id) on update cascade on delete cascade,
foreign key (published_by) references authors(id) on update cascade on delete cascade,
);
Things I have doubts about:
- I am not sure about that
published_by
column (worried about what should happen to one of these rows if its related publisher gets deleted from theauthors
table). - Whether we should store the dependencies per version (most likely as a
varchar
).
It could be useful for computing reverse dependencies, one day.