feat(ext): Unsafe sqlite #15
Conversation
| loader.init_storage(SQliteExtResources { | ||
| connection: Connection::open(":memory:").unwrap(), | ||
| }); |
There was a problem hiding this comment.
Doesn't seem like a good idea to open a new sqlite connection at startup, it should be manually triggered by the user by calling an op, just like internal_sqlite_execute
There was a problem hiding this comment.
I now see it might be used for backing a localStorage-like API, in that case, how big does embedding sqlite make the binary, and I also wonder what's the performance hit for startup. Perhaps we could lazy load the connection whenever internal_sqlite_execute is executed, I think that would be the best thing to avoid a performance hit (if there is any).
There was a problem hiding this comment.
i might do that when we can pass through pointers or external objects
There was a problem hiding this comment.
You mean resources? We can already do that
There was a problem hiding this comment.
Is Storage supposed to be backed by the sqlite? It seems to be missing an actual implementation right?
| @@ -1,7 +1,11 @@ | |||
| mod console; | |||
| mod fs; | |||
| #[cfg(feature = "unsafe-sqlite")] | |||
There was a problem hiding this comment.
question: Why is it called unsafe-sqlite instead of just sqlite? Just curious
There was a problem hiding this comment.
because its super unsafe atm and should only be used when testing new features that may depend on sqlite
|
You got a few conflicts @load1n9 |
yeah lets not use this pr, we can use it as reference for anything needing sqlite |
No description provided.