Our main query on occurrences is looking for occurrences that are

• from a given origin
• on a given branch (or all branches)
• that are the newest, or the closest to a given timestamp.

+ v0.0.21 deployed on archive

• 68a8283 Deal nicely with communication downtime with storage
• 3afbd2d Deal more appropriately with storage error

storage:

• 7e623c8 * master origin/master origin/HEAD sql/upgrades/040: add 040→041 upgrade script
• 7e2dcbc * Open directory_get to retrieve information on directory by id
• ac380c9 * Rename directory_get to directory_ls

• 'Single entity query' done in 9fe94d3, ebe3a29 (entity_get)

Current status on this:

• find objects of any type by sha1_git (release/revision/directory/content)

What about having "occurrences" for all kinds of objects in a VCS, releases, tags, revisions, etc. ?

What about having "occurrences" for all kinds of objects in a VCS, releases, tags, revisions, etc. ?
We would definitely need to look at other VCS to get a general model; for example, in Darcs patches are first class citizens: do we have a way of accomodating this in our data model?

The object_id column looks like something that we want.

I'm currently toying around with another approach for those recursive queries:

The first two points have been implemented in rDSTOc779ebdff8d2

This has been done: All the GitHub repositories where the injection was successful or unsuccessful now have an entry in fetch_history.

This is getting necessary for the Debian and GitHub listers

We're settling on a new table:

fetch_history is now getting populated by swh.loader.git.

rDSTO04bb5cb is a first approach for this.

A few proposals:

@zack points out that organization does not feel like the right term anymore.

In T3#1275, @olasd wrote:

• GitHub
  • GitHub git hosting -> GitHub lister, generates suborganizations for "GitHub organizations"
    • hylang -> no specific lister, "shallow" organization
    • zacchiro
    • olasd
    • ...
  • GitHub asset hosting -> T17

I've had some thoughts about this problem, and here are my propositions.

Inspiration :

We should make sure our abstraction works for things where the original artifact has several files (e.g. a debian source package)

shortcut query:

explain (analyze,buffers,verbose)     select origin, branch, revision                                                                                                          
    from occurrence_history as occ_hist
    where occ_hist.revision = '\x1140811ebed3b33b496a3aed32ed16b068ebffab'
    order by upper(occ_hist.validity)  -- TODO filter by authority?
    limit 1;

swh_content_find_directory query :

done in rDSTO793fb06f89d27c6ed94ab9392594dab14a941e3f

"create index concurrently ..." is now running on prado, in a screen section

see also T62

see also T22