Sqlite: caching prepared statements .... again

[vitalyd]

@donallen

No, just the prepared statements that will be used many times. Can you

suggest a better way?

Well you need the connection as well since the statement is tied to it.

An approach I’d suggest is what you said later:

@donallen

I think you need to pass the Haskell equivalent

of a struct around that contains these values, capturing the struct in

callback closures where needed).

You’d set up your connections early on in main(), prepare statements that you know a priori, and then hand out the statements as needed. These instances would be kept around (and live) for the entirety of the program and passed around as context/state where needed.

You mentioned gtk in the other post - does it require closures that you give it to be 'static? If so, yeah, you’ll need to use Rc and RefCell. This should be workable but you have to align your code structure/flow with easier borrow checking. It’s a bit of a skill (comes with Rust experience) in itself. I wrote a bit about some general strategies here: How can I get myself out of this "mutable more than once" corner I've backed myself into?. Maybe that’ll help frame your approach a bit better.

By the way, have you looked at any of the connection pooling crates? Eg r2d2_sqlite3 - Rust

@donallen

and the sqlite crates are not saying what they want to say, or

can’t say about the relationship between the lifetime of a connection and a

statement on which it depends.

I think the sqlite API says the correct thing about the relationship. A statement depends on the connection you get it from. That seems pretty uncontroversial.

@donallen

I really think this points out a serious

weakness in Rust. Rust makes it extremely difficult to talk about lifetimes

of references, lifetimes of objects and the relationships among them. When

I read the attempts to document this, both by Klabnik and Jim Blandy, the

understanding I get is not what’s going on, it’s how obscure what’s going

on really is. In this case, I think that’s why the documentation seems so

bad; memory safety without a gc is hard and maybe the design of Rust’s

lifetime system isn’t quite right, starting with how hard it is to say that

an arbitrary object, not a reference, is static. My 2 cents.

Lifetimes are not easy, but I think the friction you’re experiencing here is because of trying to shoehorn dynamic data into a 'static one. I’d be happy to try to explain some lifetime issues if you’d like - not sure if I’ll succeed but worth a shot .