So this was just an idea that popped into my head at some point and I figured I should jot it down.

If nobody else is working on making a DBI interface for Rust (similar to, but perhaps a little more coherent than Perl DBI: http://dbi.perl.org/ ), we might be in a pretty cool spot to think about that.

@kud1ing do you have any thoughts or interest? :)

The fix was planned after #94 but I was a bit late in the party. So, this commit fixes the following:

• Fixed a mistake that Database was accidentally Sendable.
• Made Cursor::{reset, clear_bindings, step, step_row, get_blob, get_int, get_i64, get_f64, get_text, bind_param, bind_params} receive &mut self.
• Made Database::set_busy_timeout receive &mut self. Database::{prepare, exec} has been left as is, since it is perfectly safe to have multiple cursors (see prepared_stmt_bind_static_text_interleaved test for an example). The associated thread safety issue is handled by making Database non-Sendable.

Closes #98, #99, #100, #101 and #103.

I was just looking over things since #26 was raised, and thinking that the bundled sqlite should probably either be removed or updated, since it was last updated a year ago, and I know there have been quite a few updates since then.

Cursors now borrow a pointer to the database handle. This changes the prepare() api.

If you turn on debug logging before applying this commit, you can see the database's Drop running before the cursor's.

I'm no rust expert, so this may not be the best way.

This is a threadsafety problem.

In Rust, safe code provides several guarantees: that aliased data cannot be mutated, that mutation is only possible through unique paths, that data races cannot happen, that invalid memory cannot be accessed, that references cannot outlive their referents, etc.

If you are going to directly wrap C functions that do not provide these guarantees, you need to mark your functions unsafe. Otherwise you are violating the contract of the language and putting your users at risk.

Sqlite4 is coming and will probably overtake sqlite3 at some point in the future. It would be good to future-proof these bindings in anticipation of that. Two things I can see are:

• get_num could be renamed get_f64. Sqlite4 is going to have sqlite4_num, a decimal instead of binary floating point representation, ( http://sqlite.org/src4/doc/trunk/www/decimal.wiki ) so this naming would be confusing to a future users who are more familiar with sqlite4.
• This is a more annoying change, but: the crate could be named and linked as sqlite3 instead of sqlite. Otherwise, some future version of rustpkg may end up with an often-used "sqlite4" package and a rarely used "sqlite" that shadows it in the autocomplete.

I'm perfectly willing to do these changes, but I thought it would be good to see what other people thing before doing something with so much API change.

Hi! First of all, cool project ;-)

I tried it out (am still new to Rust) and arrived at a segfault. Thought you'd like to know about it if you don't already.

I'm running the master version of both rustsqlite and Rust.

It may just be a transitioning thing (I know Rust is changing and breaking all the time), but it's a bit difficult for me to tell the difference.

Anyway, here's the code: https://gist.github.com/brinchj/7363049

I tried running the code through valgrind, but it doesn't seem to give me anything useful. Except perhaps that it seems to be telling me that the segfault is in finalize: ==31159== by 0x713477E: sqlite3_finalize (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) ==31159== by 0x5D936C9: cursor::Drop$Cursor::drop::h96b05de1db21bd53ioao::v0.1

If I comment out the bind_param line, the program runs fine. And it only seems to happen with Text. Integer doesn't segfault.

It seems @erickt somewhat duplicated sqlite.rs into sqlite.rc in https://github.com/linuxfood/rustsqlite/commit/eb89e85580a54fd390c355642c571cd1d6701789#sqlite.rc

sqlite.rc appears to be more up-to-date.

Should sqlite.rs be removed?

There were a couple other last minute changes that broke rustsqlite. This fixes them, and also switches over to using send_maps instead of hashmaps, as that gets rid of the "no-implicit-copies" warnings.

To do is some library modernization, such as converting over to structs, and getting it to work well with serialization. That'll come in a little bit.

https://travis-ci.org/linuxfood/rustsqlite

rustup.sh seems to await an interactive input which times out:

You may uninstall later by running /usr/local/lib/rustlib/uninstall.sh,
or by running this script again with the --uninstall flag.

Continue? (y/N) 

No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself.

Maybe pass the --uninstall flag?

See marker.rs for some discussion of the current state of marker traits. The upshot is that Copy is opt-in, so we don't need to explicitly opt out with a _nocopy field, and Database automatically does not implement Sync because it has a *mut dbh field.

After this change, this project is compatible with the beta release of rustc. :)

A RowMap is defined as a HashMap<String, BindArg>. I am relatively new to Rust, and maybe that is why, taking values out of a RowMap is annoying:

let text = match row_map.get("somekey") {
    Some(BindArg::Text(ref val)) => val.clone(),
    Some(_) => panic!("Wrong type"),
    None => panic!("No such column")
};

Am I missing something? Is there a better, less verbose way of doing this? If not, I propose this:

pub trait TypedGet {
    fn get_text(&self, key: &str) -> Option<String>;
    fn get_float64(&self, key: &str) -> Option<f64>;
    fn get_integer(&self, key: &str) -> Option<isize>;
    fn get_integer64(&self, key: &str) -> Option<i64>;
    fn get_blog(&self, key: &str) -> Option<Vec<u8>>;
}

impl TypedGet for RowMap {
    fn get_text(&self, key: &str) -> Option<String> {
        match self.get(key) {
            Some(thing) => match *thing {
                BindArg::Text(ref val) => Some(val.clone()),
                BindArg::Null => None,
                _ => panic!("No text found"), // Or maybe change the return type to Result<Option<String>, String> and Err here?
            },
            None => None,
        }
    }
    // And so on for other trait fns...
}

This will allow people to import the TypedGet trait and then use these methods instead of writing their own similar utility methods.

Another solution (maybe better) could be to implement these methods on the enum BindArg itself.

impl BindArg {
    pub fn get_text(&self) -> Result<Option<String>, String> {
        match *self {
            BindArg::Text(ref val) => Ok(Some(val.clone())),
            BindArg::Null => Ok(None),
            _ => Err("No text found".to_string()),
        }
    }
   // ...
}

But I'm not sure if there is already a better way around this. Thanks.

rustsqlite doesn't expose a way to query the database for the error message for the failure of creating the database since the binding closes the db handle, so Database::get_errmsg cannot be called. Also sqlite3_errstr is apparently not exposed.

The function sqlite3_errmsg returns the error message from "the most recent call". If this is going to be exposed then every single function calling a sqlite3_* function needs to take a mutable self, otherwise this function will be racy.

Probably the better thing is to not expose this message and instead bundle its result into any Errs that are returned from SqliteResult-returning function, since it is not very Rustic to have error reporting be separated from error occurance like this.

The idea is the client declares a strict with deriving Encodeable; then query results come back as an iterator over that type.

Likewise, bind variables for a statement can be set from a a Decodeable struct or perhaps even a tuple.

I hope to work up a PR.

As per rust-lang/rfcs#109, rustsqlite now produces libsqlite3.rlib which shares a same base name with SQLite (libsqlite3.a) and causes a name conflict when linked by other crates. It can be resolved either by giving -C extra-filename=_rust (or similar) to rustc, or by renaming the library. It may also be made a non-issue when Cargo may resolve this as well.

Hi, Any chance of some up-to-date examples, or can you point me to some up-to-date examples? The main thing currently that I need to do is a SELECT with NEXT or similar and extracting column values. I've seen highlow, but I believe that's not up-to-date.