Data layer: Backend behind the seam

Abierto
  • ¿Algo no está bien?
#601 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
28/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
csharp, typescript
Área
backend, database

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
TypeScript
Estrellas
2
Forks
0
Merge medio
1 d 6 h
PR fusionados (30 d)
88

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de sillsdev/interlinearizer-extension

Todos los issues de sillsdev/interlinearizer-extension

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.