Skip to content

Store database version metadata in the database #7

Open
@Hirevo

Description

@Hirevo

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 the authors table).
  • Whether we should store the dependencies per version (most likely as a varchar).
    It could be useful for computing reverse dependencies, one day.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions