StorageProvider development
#91
Conversation
sandreae
changed the title
Operations and DocumentViewsOperationStore and DocumentStore
|
I've changed the Also I had a quick renaming (based on our conversation on our chat), hope that was alright! I can see that this might not be the final structure and things will still move but I could identify a few building blocks, hopefully this helps a little:
|
| /// the db as this method only creates relations between document view fields and their current | ||
| /// values (last updated operation value). | ||
| /// | ||
| /// QUESTION: Is this too implementation specific? It assumes quite a lot about the db |
There was a problem hiding this comment.
Does this need to be implemented for p2panda_rs? I agree, this implementation is too specific for something else than aquadoggo SQL, but I'm sure we can a) either find something else for a more "generic" p2panda_rs version b) or just leave it unimplemented?
There was a problem hiding this comment.
We need an insert_document_view() method in p2panda_rs, but exposing the details of how we're doing that is too specific to our db layout, yeh. I would say that we should develop DocumentView to contain the data we need though, as it's useful and not too much overhead, then the signature for this method could be something like:
async fn insert_document_view(
&self,
document_view: &DocumentView,
schema_id: &SchemaId,
) -> Result<bool, DocumentViewStorageError>;
I'll open an issue for changes in DocumentView.
| // - alternatively we could do some dynamic "reverse" graph traversal | ||
| // starting from the document view id. This would require | ||
| // implementing some new traversal logic (maybe it is already underway | ||
| // somewhere? I remember @cafca working on this a while ago). |
There was a problem hiding this comment.
Yeah, I was so sure that @cafca was working on this and even merged it, but now I can't find it anywhere 🕵️
|
Thanks for the branch organising 👍 and all the naming makes a lot of sense! |
sandreae
changed the title
OperationStore and DocumentStoreStorageProvider development
|
I'm retiring this PR and splitting it into a series of smaller ones, goodbye my friend. ⛵ First up: |
Overview
Operationss,DocumentViews andDocumentsOperations andDocumentViews.p2panda-rsEntryStoredefined here: Entry store additions p2panda#310 which implement replication methods. I wanted to split them out into there own PR but really haven't found a good way to do it.... 😭References
Todo:
OperationStoreandDocumentStoreneeds improvementget_next_n_entries_after_seq()inEntryStoreas the default implementation will be very inefficient as it would end up with repeated db requests for each entryDocumentStoreis the least developed, a few areas which need work spring to mind:DocumentViewfromget_document_view_by_id()find_all_related_views()operation_field_v1table or by splitting the fields into their own typed tables (as @cafca sketched out)Documentmethods we need.Notes
Do we not want to usefor now we avoid using it as we aren't clear of the implications.FOREIGN KEY(x)for relations in the SQL tables, as we don't know the order items will be added to the db?SchemaHashIdfor a shortened unique id to identify schemas with potentially ever groupSchemaIds. However, if an operation follows a system schema, then it already has a short identifier, and so it won't be hashed... Shall we call it sometihng else in the db? Likeschema_id_short? Which will be a{name}_{schema_id_hash}in the case of an application schema, and{name}_{version}in the case of a system schema?Next
SchemaStoreAuthorStore📋 Checklist
CHANGELOG.md