I've seen a lot of people making the mistake of trying to put things
like `diesel::types::Timestamp` in their structs. This attempts to
better document the role of the `types` module, and documents any
`ToSql` and `FromSql` impls that are provided. I've un-inlined the pg
types module, as stating "this is a postgres specific type" in the
documentation over and over again didn't feel right. I've also made sure
that the UUID feature is turned on when generating docs.
Having the same crate for both has caused a ton of problems with
linking. I had hoped to just use cargo features for this, but it wasn't
working out that way.
`diesel_codegen` now only targets nightly. `diesel_codegen_syntex`
handles syntex separately (and also contains the common code between the
two crates). Neither crate includes the postgres feature by default.
How to migrate
--------------
If your Cargo.toml previously looked like this:
```rust
[build-dependencies]
diesel_codegen = "0.6.0"
```
it should change to
```rust
[build-dependencies]
diesel_codegen_syntex = { version = "0.7.0", features = ["postgres"] }
```
(You'll need to change the `extern crate` line in `build.rs`)
If your Cargo.toml previously looked like this:
```rust
[dependencies]
diesel_codegen = { version = "0.6.0", default-features = false, features = ["nightly", "postgres"] }
```
it should change to
```rust
[dependencies]
diesel_codegen = { version = "0.7.0", features = ["postgres"] }
```
I've had to split out the cargo features in our test suite, since Cargo
doesn't give me a way to say "turn on the
diesel_codegen_syntex/postgres" feature only if the `with-syntex`
and `postgres` features are on, and I don't want to have to build syntex
every time I run the tests against nightly.
Had to delete the test for the owned value to insert. Message involving
the types is now a note not part of the error. Unsure if this is because
it *actually* changed to a note, or if it's a quirk in compile_tests
0.2.0 (if I test for the note I need to specify *all* notes and the note
on the overflow error is enought o make me not want to do that
We were affected by breaking changes with how struct fields are
represented. Now that I can get the tests compiling, I noticed that I
implemented the `Option` impl for specialization incorrectly.
This was removed earlier because if a diesel_cli test started failing,
it would abort the entire test suite because it exited with a status
code of 1, which rust interprets as a problem. Now, because we shell out
all our tests that ever hit this part of the code, we can go back to
printing errors and exiting 1. This presentation is much nicer than a
panic.
`time2` has been stabilized (with some API changes, which we need to
match). We still need it behind the `unstable` feature for another 6
weeks until it's stabilized. Unfortunately, quickcheck has been
unresponsive on updating to address this. I've simply commented out that
test for the time being.
Because `Connection` isn't object safe (and probably shouldn't be),
switching based on the desired backend had to be achieved through
branching, handled with a macro wherever possible. This will obviously
grow more and more burdensome as more backends are added, and a better
solution will have to be figured out in the future.
I also split out database related functions into their own module, as it
was starting to feel like too much to juggle in one file.
The tests in the `database` mod each use their own database, as for many
of them we're dropping and creating the database, which can't be wrapped
in a transaction. Using a separate database for each allows us to still
run the tests multi threaded, but does add the extra cost of some setup
and teardown in the code.
The Sqlite portions don't use the `temdir` crate for generating their
database path because I couldn't figure out an ergonomic way of keeping
the tests able to run for both backends, while keeping the TempDir in
scope (returning a path from a function causes the TempDir to go out of
scope, which removes the directory in its destructor).
I want to write some tests confirming that PG expressions don't compile
on SQLite. These are only meaningful when tested against Diesel with
both SQLite *and* PG enabled, which we explictly don't want to do in the
main test suite.
While the tests were passing previously, we didn't actually build if you
compiled without libpq installed on your system. This corrects those
issues, and the failures that resulted from it. There are several places
where I'm legitimately unsure how the code compiled before this change.
I've had to do some janky things to codegen to make it actually work, as
there's an issue where cfg attrs aren't properly applied inside of
`include!`. This is why the dummy version has to exist, and why it warns
instead of errors. It might make sense to just define the macro as a
no-op in the future.
All code which *directly* depends on these has been moved to a separate
module and placed behind a cfg attr. There is still a ton of PG specific
stuff hidden in the expressions module that simply isn't marked as such.
I had to rework how we do our boilerplate type impls, as `sqlite` and
`postgres` need to be able to co-exist in the same compile pass (even
just for generating docs).
While this PR is pretty large, it ultimately mostly comes down to
clerical work.
Fixes#159.
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
