SQLite Forum

Wishing CLI could be usefully embedded
Login
> (3) The primary DB connection
> (5) Coordination between DB closing

In embedded mode, the pimary DB connection can be coming from the host.  
I.e. one should neither open nor close it.

In my case, it is **the** DB with all the vtables representing the state  
of the C++ host application, which only the host app can configure, and  
which the host app will continue using once the embedded shell *exists*.

The embedded shell can open other connections (recent addition), or attach other DBs.

If attaching other DBs to the primary host-managed connection, once might  
wonder whether the shell should detach those, or let them attached, to be  
available again later if/when another embedded shell is re-started.

I think leaving them as-is makes more sense. The host can setup an [authorizer][AUTH]  
if it wants to, to prevent or know about those, and detach them *post* embedded-shell *exit*.

Regarding your thinking of a struct and a main()-like entry point.  
Why not replicate the design of SQLite itself, with the shell taking  
an optional VFS, defaulted otherwise, and a new VIO (Virtual IO) interface  
specific to the shell? I.e. make the shell a stateful object to new/config/close?

[AUTH]: https://www.sqlite.org/c3ref/set_authorizer.html