Add file-backed SQLite CRUD UI projects#62
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6306f7ded4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| private WorkspaceStorage targetStorageFor(final WorkspaceStorage currentStorage) { | ||
| if (WorkspaceStorage.MODE_SQLITE_MEMORY.equals(currentStorage.mode())) { | ||
| return WorkspaceStorage.sqliteMemory(); | ||
| } | ||
| return WorkspaceStorage.memory(); |
There was a problem hiding this comment.
Preserve file-backed storage during schema upgrades
When a schema upgrade is applied while the workspace is using sqlite-file, this helper falls through to memory(). The upgraded workspace is then replaced with an in-memory store, so subsequent edits are no longer persisted to the project's data.sqlite and a default project save switches the project to JSON. Keep the existing SQLite file storage (or explicitly migrate it) for this mode as is already done for SQLite memory.
Useful? React with 👍 / 👎.
| private String resolvedStorageMode(final String storageMode, final String dataFile) { | ||
| String validated = validatedStorageMode(storageMode); | ||
| if (STORAGE_MEMORY.equals(validated) && looksLikeSqliteFile(dataFile)) { | ||
| return STORAGE_SQLITE_FILE; | ||
| } |
There was a problem hiding this comment.
Do not infer SQLite storage solely from the filename
A manifest that explicitly uses storage.mode: memory (or an older JSON-only manifest) with a valid JSON dataFile ending in .db, .sqlite, or .sqlite3 is forcibly reclassified as SQLite here. Project loading consequently opens JSON as SQLite rather than following the explicitly declared mode, making those valid projects unloadable. Only apply extension/header detection when storage is absent or otherwise unambiguous.
Useful? React with 👍 / 👎.
| await addTextProjectFile(files, directory, "projectfile.erproj", true); | ||
| await addTextProjectFile(files, directory, "schema.yaml", true); | ||
| await addTextProjectFile(files, directory, "data.json", false); | ||
| await addBinaryProjectFile(files, directory, "data.sqlite", false); |
There was a problem hiding this comment.
Read the manifest-selected files in browser project loads
Browser loading uploads only the default schema.yaml, data.json, and data.sqlite names. Valid manifests can select different relative schema/data filenames (including the supported dataFile: todomanager.sqlite form); load-files later resolves the manifest's filename in the temporary folder and reports it missing because this client never uploaded it. Parse the manifest first and upload its declared files, or upload the folder contents safely.
Useful? React with 👍 / 👎.
Summary
Adds file-backed SQLite storage support for CRUD UI projects and rounds out the project save/load workflow.
What Changed
dataFilecan point to JSON or SQLite, with SQLite autodetection for human-edited manifests.data.jsonand SQLite projects savedata.sqlite.Validation
node --check thingifier-crud-ui\src\main\resources\public\assets\app.jsmvn -pl thingifier-crud-ui -am verifyCloses #52