The version that is in the container infrastructure is from 2011. We use
`sqlite3_errstr` which was added in 2012. The switch to the "trusty"
infratstructure bumps it to 3.8, which is relatively recent.
This exposes a legitimate bug related to nul bytes in string fields that
for some reason not replicating for me locally.
This commit adds all of the guts for SQLite3 support to Diesel. There
are several outstanding issues which will need to be resolved before
this is ready to be merged into master. This commit will not be merged
into master until these issues have been resolved.
Ultimately the most difficult remaining problem which we need to address
is the lack of a `DEFAULT` keyword. I will detail why this is a problem
and what I think we can do to solve it in a separate issue.
SQLite has a fundamentally different mechanism for handling bind
parameters than pretty much every other backend out there, where the
function you call differs based on the type, rather than sending an
array of bytes and telling the backend how to interpret it. `FromSql`
had to be updated to address this (see
8a33029944
for details on that). I have not applied the same change to `ToSql`, as
it was possible to shoehorn SQLite into our existing structure. While
this may end up changing in the future, I do not believe it is necessary
for 0.5.
I'm not super happy about the structure of `StatementIterator`,
`SqliteRow`, and `SqliteValue`, as ultimately the `Row` is a giant lie
and `Statement` is the the value that maintains all of the state.
Ultimately this comes out of the weird interaction between the fact that
`Row#take` returns a reference, but sqlite's C api doesn't actually
return a single value that works in that sense (and really doesn't have
the concept of a row at all). As with much of our code overall, this can
probably be cleaned up in the future by having the `Backend::RawValue`
directly be a reference for `Pg`. I need to figure out a way to
accomplish this without adding a lifetime to the `Pg` struct.
I've broken our test suite into postgres specific and general where
possible, but this is a *very* incomplete process. There are several
modules which are entirely scoped to PG that do not need to be, which
can be addressed independently in later PRs. Additionally, the entire
`expression` module needs to be for expressions which are specific to
PG. I do not believe that SQLite has anything specific to it which is
not also supported by PG.
Fixes#39 (mostly. Enough to close the issue at least)
The first attempt at adding support for `chrono::NaiveDate` was
completely incorrect. This was in part due to the fact that I never
tested for some known values. Combined with the fact that I've
discovered quickcheck is testing a much smaller set of values than I
thought (which would likely expose some bugs), I wanted to make sure
that our existing tests for real values are at least valid.
The quickcheck tests need to eventually be updated, as `PgDate` will not
in fact round trip for values below -200000ish (earlier than Julian
era), it will silently insert null.
The latest nightly is currently failing due to the `rand` crate, and
there's really not much I can do about it at the moment. Since `nightly`
is an allowed failure, we'll ship when stable passes instead.
There were upstream changes in rustc, which have been resolved in aster,
quasi, etc, but the versions that will resolve as it is no longer build
on 2015-12-30
This macro takes a database connection at compile time, inquires about
the schema, and invoke the `table!` macro for you automatically. This is
an early pass, and it doesn't support any types from third party crates,
or custom primary keys (I'm not even 100% sure that it won't error some
of the time on types that we do support).
Right now we're going off of the type name and capitalizing it to find
the right type. I'm unsure if we'd be better off using the OID (and then
the aliases would be `Oid6342 = Array<Json>` or whatever). We do need to
decide that before 1.0, as it'll be a breaking change for third party
crates.
I've had to do some funkiness in our tests, where basically I set up the
schema on a separate database from where our tests run. This is because
our suite assumes that we can rely on the id 1, which means the table
has to be created in that test. I cannot drop the tables before the
tests run, because on nightly I don't have a place to execute code after
compilation finishes.
As such, this doesn't actually make our tests look much cleaner, but
once we refactor to work w/ persistenct schema we should be able to
remove a lot of code.
This introduces syntex as a dependency on stable, which will pre-process
the appropriate files for annotations. We need to document this process
somewhere.
Fixes#15
Wow, so apparently we don't built on stable or beta, not because of the
compiler plugins, but because `For<i32> for i64` isn't on stable, and
`For<i32> for f64` is only on nightly. Additionally, there was a
breaking change in compiler plugins *tonight*, which I've updated for
(and am pointing at a local branch for dependencies until it gets fixed
upstream).
Sorry for the breakage folks, I know it's a pain. Update to tonights
nightly, it's now the only thing we work on, because I don't know how to
make travis go to last nights. We'll be on stable by the end of the
week.
Ok, I mean I knew that our tests wouldn't work yet because I haven't
added syntex, but that's not even the problem. Apparently the *real*
reason we don't work on stable is that `From<i32> for i64` is only
implemented on beta and `From<i32> for f64` is only nightly. I figured
there were reasons I couldn't target stable, but really????
