mirror of
https://git.asonix.dog/asonix/pict-rs
synced 2024-12-22 11:21:24 +00:00
Update postgres doc
This commit is contained in:
parent
bd3975f455
commit
c30c01f0bb
1 changed files with 6 additions and 20 deletions
|
@ -25,34 +25,24 @@ FullRepo that depends on the others to ensure everything gets implemented proper
|
||||||
only been one repo implementation so far, it's not optimized for network databases and some things
|
only been one repo implementation so far, it's not optimized for network databases and some things
|
||||||
are less efficient than they could be.
|
are less efficient than they could be.
|
||||||
|
|
||||||
Some of the existing repo methods could be consolidated to better represent the data and operations
|
|
||||||
that need to be performed. This should happen _before_ implementing the postgres repo.
|
|
||||||
|
|
||||||
|
|
||||||
### HashRepo
|
### HashRepo
|
||||||
This is a little complicated because one of the things a HashRepo can do is return a stream of
|
This is a little complicated because one of the things a HashRepo can do is return a stream of
|
||||||
hashes from the repo. This can likely be implemented as a batch-retrieval operation that fetches
|
hashes from the repo. This can likely be implemented as a batch-retrieval operation that fetches
|
||||||
1000 hashes at once and then drains them on each call to `poll_next`
|
1000 hashes at once and then drains them on each call to `poll_next`
|
||||||
|
|
||||||
This is also probably made up of multiple tables, and can reuse some other tables. It's likely that
|
|
||||||
some of this functionality can be consolidated with AliasRepo. In both usages, relate_hash and
|
|
||||||
relate_alias are called together.
|
|
||||||
|
|
||||||
Create could also maybe be updated to take the identifier as an argument, since it doesn't make
|
|
||||||
sense to have a hash without an identifier. This might affect the ingest process' ordering
|
|
||||||
|
|
||||||
methods:
|
methods:
|
||||||
- size
|
- size
|
||||||
- hashes
|
- hashes
|
||||||
- create
|
- create
|
||||||
- relate_alias
|
- update_identifier
|
||||||
- remove_alias
|
- identifier
|
||||||
- aliases
|
|
||||||
- relate_identifier
|
|
||||||
- relate_variant_identifier
|
- relate_variant_identifier
|
||||||
- variant_identifier
|
- variant_identifier
|
||||||
|
- variants
|
||||||
- remove_variant
|
- remove_variant
|
||||||
- relate_motion_identifier
|
- relate_motion_identifier
|
||||||
|
- motion_identifier
|
||||||
- cleanup
|
- cleanup
|
||||||
|
|
||||||
```sql
|
```sql
|
||||||
|
@ -83,15 +73,11 @@ UUIDs in all recent versions of pict-rs.
|
||||||
|
|
||||||
methods:
|
methods:
|
||||||
- create
|
- create
|
||||||
- relate_delete_token
|
- delete_token
|
||||||
- relate_hash
|
|
||||||
- hash
|
- hash
|
||||||
|
- for_hash
|
||||||
- cleanup
|
- cleanup
|
||||||
|
|
||||||
This can probably be simplified. If `create` took a `hash` as an argument and returned a
|
|
||||||
`delete_token` we could have all of our required information up-front and avoid the hassle of
|
|
||||||
generating each part of this separately
|
|
||||||
|
|
||||||
```sql
|
```sql
|
||||||
CREATE TABLE aliases (
|
CREATE TABLE aliases (
|
||||||
alias VARCHAR(30) PRIMARY KEY,
|
alias VARCHAR(30) PRIMARY KEY,
|
||||||
|
|
Loading…
Reference in a new issue