unfortunately the implementation of the message dispatching is handled by a NIF, and the convention for that NIF is to use charlists, because the lib is an Erlang library, not Elixir. Charlists are also faster for NIFs if i remember correctly, since it doesn’t have to allocate, convert to term, deallocate etc.

I don’t think Ecto encourages looking up a schema module at runtime, since multiple schemas could use the same table.

I guess dispatching the rowid isn’t that bad. I could make a wrapper module that one could use by supplying a schema and translate it for the user.

I don’t think its a private api, just part of how the Sqlite3 virtual machine works. You can read about rowid here. Basically it exists, and you can use it to index things, but you can’t look at how it works. (as far as my limited knowledge of the sqlite public api goes anyway)

In most cases the rowid is the primary key, (although this isn’t always true), the only problem is that sqlite internally doesn’t actually dispatch the callback (what sends data back to Beam) until after the row has been destroyed.

There actually is commit and rollback hooks (described here) but that would add more complexity to the NIF than i would ideally give it.

That would be perfect, at least for me, I think.

The nif handles messages in a thread, so it’s possible that messages can come in faster than they can be handled, but they should be received in order making this not that big of a deal i don’t think

Fair enough, I figured. At this point you’d basically be making Sqlite++ with half the code being the original Sqlite (C++) and the other half Elixir. Far from ideal.

So it’s kind of a private API? Maybe you can ask the maintainer if you can make use of that journalling metadata before it gets GC-ed?

Sorry I am not very helpful, mostly just thinking out loud.