Data layer: Backend behind the seam

Aperta
  • Qualcosa non va?
#601 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
28/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp, typescript
Ambito
backend, database

Direzione di ricerca

Start with #584's C# repository and the existing seam, then read the suite's undo group and EditHistory for how undo and redo are currently exercised. The proposal leaves key design questions open, including Discard behavior and milestone scope. Done means a session runs on the C# repository behind a flag with undo and redo, while today's storage remains the default.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

This is a post-Phase-5 proposal, not a set of decisions. It's a starting point to discuss and change.

WebView sees: Nothing. Releasable because: the C# repository runs only behind a flag; today's storage stays the default.

Proposed direction

The CRDT store would keep no drafts: every edit persists. Save would go away. Undo and redo would use the CRDT's own history. Discard would stay in some form, with bookkeeping outside the CRDT if needed.

Scope

Plug #584's C# repository in behind the seam. Whether this is Phase 7 of the Host-owned data layer milestone or opens the next milestone is open (below).

The C# repository can be built against the suite's required group (#591, in #597) with none of these settled. They matter once a session runs on it.

⚠️ The revert in the first row below is the one piece of C# design here. Undo, redo, and Discard all build on it, so it is worth settling early (though it doesn't block #591).

Piece What it takes Where it stands Side
Undo and redo through the CRDT's history Revert a given commit by writing a new one, keeping teammates' later changes to the same records. The seam would gain undo and redo calls that reply with a change set, and the suite's undo group, which tests apply's inverse, would move to them #584's Apply returns no inverse, and none would be needed. FW Lite has no undo over Harmony to reuse. Harmony drops a second create under an id already stored, even a deleted one (#597), so reverting a delete has to undelete the record, not create it again; reverting a project delete has to undelete every record the delete took with it C# for the revert; TS for EditHistory and the suite
Deletes that cascade A ChangeBuffer guard that refuses deleting an analysis while a kept link names it Commands delete an analysis only once nothing links to it (reclaimIfUnlinked), so today only a test produces the case. Behind the seam, C#'s cascade would be a change no change set reports. #597 adds a second cascade: deleting an interlinear project deletes its records, and a record created in a deleted project lands deleted TS
Session open and discards without exportAll (#588) Read the scope record and a query instead of the whole draft Matters once the backend is in C#, where the whole draft would cross PAPI. #597's readAll command is that read, for the conformance suite TS
Record timestamps Keep what a put carries, as DraftRepository does, or stamp the commit time, as #584 does Undo would no longer need a put's timestamps; imports, and Save As if it survives, still rely on them. The suite's required group leaves timestamps out of its comparisons, and a DraftRepository test pins today's behavior Either: a small C# change, or TS changes to what relies on it
Scope record (boundaries, languages) Map it onto #597's InterlinearProject entity, or stay in today's storage #597's entity carries the name, description, target project, analysis languages (added and removed by name), and one segmentation delta with no split by book. CSharpRepository still refuses a change set carrying the scope record TS for the mapping; C# if the entity's shape changes

Done when: a session runs on the C# repository behind a flag, undo and redo included, with today's storage still the default.

Before the C# repository becomes the default

Question Proposal Why it waits
Discard Revert this client's commits since a point, newest first, with their commit ids kept in host storage outside the CRDT Needs the revert above, and the Discard point (open questions)
Save, Save As, the unsaved mark Save would go. The unsaved mark could become "commits since the Discard point" Follows from Discard; Save As is open
New Would create the interlinear project at once (#597's createProject), since apply refuses a project its source's database doesn't store and there is no draft to hold work before it exists Follows from dropping drafts

Later

Question Options Why it waits When
Re-anchor passes Stored as commits, or derived on read Only matters once two clients sync the same store Before sync ships
Shards for projects Likely never needed Only if drafts go away before the CRDT store replaces them If at all
When data stops being disposable Pick the moment on purpose Once a shared, synced store ships, schema changes need migrations and the change-set shape gets much harder to change Before the first synced store ships

Open questions

  1. Where does Discard rewind to: session open, a marker the user sets, or the last sync? Does its list of commits survive a restart?
  2. Does Save As survive, as copying a project to a new one, or go with Save? A copy would mint new record ids, since #597 refuses a put under an id stored in another project.
  3. Should this be Phase 7 of the Host-owned data layer milestone, or open the next milestone? Its done-when goes past the current milestone's.
Lingua principale
TypeScript
Stelle
2
Fork
0
Merge medio
1g 6h
PR unite (30g)
88

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sillsdev/interlinearizer-extension

Tutte le issue di sillsdev/interlinearizer-extension

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.