Minimal sqlite version of sdk v2

[samuelstroschein]

Context

We want to test building inlang on sqlite. The time savings from using sqlite could be tremendous.

Goal

Force a decision on sqlite based inlang sdk by July 19.

• Is the implementation of the sqlite based SDK simpler?
• Will we be able to iterate faster based on sqlite?

Must have requirements for the prototype

• CRUD operations (work out of the box)
• ID generation on insert (sqlite function?) - generation happens on the consumer side

MESDK-155

MESDK-137MESDK-137

Nice to have's but not important

• different "better" relational data model than we currently have in the rxdb version
• validation of inserted data

Out of scope

• reactivity
• persistency other than opfs (node fs). if it runs in the browser, running sqlite in node will be trivial.

[samuelstroschein]

Here is the pre-existing prototype https://github.com/samuelstroschein/inlang-on-sqlite-prototype.

We can take it and adjust:

• the data structure to be identical to the rxdb version for ease of implementation
• fake reacitivity via polling
• store the settings.json in a file table like sqlite archives https://www.sqlite.org/sqlar.html
• lint reports in it's own table

[martin-lysk]

Fink:

Features we wont implement:

• no branch switching
• no project selection (only one inlang file is open?)
• no login
• no history (lix)
• no merging (lix)
• no revert or commit

Fatures needed:

• filter
  • Languages
  • reported lints
  • messageBundle Ids
• text search within variant patterns (taking into acount filtered messages)
• resulting bundles from filter and search need to be reactive
  • Most cpu expensive query - Test how does it perform with text search on 250k+ variants
    • could be limited for ui's - but to find nothing a full table scan will always be need
  • join over MessageBundle/Message/Variant/LintReport
• crud on
  • messageBundles
  • messages
  • variants
  • settings
• naiv Linter implementation
  • needs to run in a worker to not block main thread (guess we need to open the sqlite from the worker)
    • crud on lints from a worker
    • read of messages from a worker
    • drops all reports and inserts the results as they come in - batching to not exceed sqlite's character limits

Investigation question:

• how does it work in envs where opfs is not wanted (sherlock?) or not possible (parrot?)