We now point to docs.rs for the documentation of the latest release
instead of docs.diesel.rs which contains documentation rendered for the
master branch.
The readme now contains both links you might be reading it in context of
Diesel's Github repo page or on crates.io. I also changed the
diesel_codegen documentation entry to point to the guides listing page,
as there are multiple guides (some just drafts right now) that talk
about the derives.
[ci skip]
Hi! I don't have bandwidth for full doc sets, so I just edited the README + Contributing.md—making small changes. Some suggestions for the README:
Take a look at this product analysis template (https://github.com/zalando/zalando-howto-open-source/blob/master/producttemplate.md) and use it to create an Intro section in your README that answers these questions:
— what inspired/prompted you to make this?
— do you have metrics/other evidence showing its usefulness?
— any user testimonials showing its value?
— what is this like/not like; or is it the only one of its kind?
Thanks for submitting your project. :)
This is by far our biggest release yet, including 162 commits by 9
contributors. You can view the full changelog at
https://github.com/sgrif/diesel/blob/v0.5.0/CHANGELOG.md
To coincide with this release, we've launched a new website. Check it
out at http://diesel.rs -- We've also published a new Getting Started
guide.
By far the biggest feature of this release is support for SQLite3 as a
backend. If you'd like to try it out, add `features = ["sqlite"]` to
`diesel` and `diesel_codgen` in your Cargo.toml. PostgreSQL is still
included by default. To remove it, add `default-features = false`.
Additionally, this release adds support for the various types from the
`chrono` crate. Add `features = ["chrono"]` to enable it.
Some of the more minor features include the ability to opt into the
0.2.0 behavior for updates (treating `None` as `NULL` instead of
skipping the field), as well as support for the `sum` and `avg`
functions.
Unfortunately, there were some breaking changes in this release that are
likely to have a broad impact. `diesel::Connection` is now
`diesel::pg::PgConnection`. `load` and `get_results` now return a `Vec`
instead of an `Iterator`. `Queriable` has been renamed to `Queryable`.
This release was a huge group effort to make happen, and we hope you
enjoy it. Happy Dieseling!
Thank you to Diesel core team, and the contributors to this release:
@oursonguimauve
@robertmaloney
@tamird
@tessgriffin
@weiznich
We still need to have the designer do another pass on that page, but the
content there is *much* more up to date than what we have on the README
right now, and I don't care if the formatting is a bit off for the time
being.
This might move around a little bit more, but I want to just be able to
write `diesel::update`, the `use` statements for those functions are
really common and quite noisy. This means that we need to stop
recommending glob importing the top level, and give something to be glob
imported.
I *think* I want to re-export the prelude from the top level, but I'm
not 100% certain. An alternative would be to export some of our structs
from the prelude as well.
Fixes#93
This should be expanded further, but I want to scrap most of the README
and do a better guide (e.g. I don't think we need to mention `table!`,
at least not before mentioning `infer_schema!()`)
/cc @mfpiccolo
`infer_schema_from_table!` calls `table!` for you automatically for a
single table. `infer_schema!` loads the table names from the database
and calls `infer_schema_from_table!` for you automatically.
Fixes#40.
Yes, one day later. There were a couple of breaking changes that became
clearly needed. I didn't expect this to get as much traffic as it has,
so I'd like to get these changes made before too many people rely on the
old behavior. See the CHANGELOG for specific API changes.
This was a wart from the earliest days of implementation. It's
inconsistent, and feels weird in place with the rest of the commands.
I felt weird about the `Copy` bound on `InsertStatement`, but it ends up
being required and makes sense when you consider that we'll always be
passed references. However, it can potentially lead to some confusing
error messages.
The old methods on `Connection` are deprecated, and will be removed in
the next release.
Fixes#30.
These are intended to be used in favor of `query_one` and `query_all`,
which are now hidden from the public API. I originally was going to name
these `run` and `run_all`, but I didn't like the name `run_all`, nor the
fact that `run` and `execute` are synonyms ("Do I call `memcpy` or
`memmov` here?")
Fixes#29
Using `update` and `delete` was previously quite annoying to write. This
makes the API feel much more fluid, and reads better if you're not
actually using the count. Since `insert` is coming in this release as
well, this will make things more useable.
Some of the code in the README has been updated for
cbe24710f6,
and is incorrect on 0.1.0. Some of the documentation examples are
incorrrect still, but I'm going to push 0.2.0 tomorrow, and I'm
intending to keep the API relatively stable, so hopefully this won't be
a problem that needs solving longer term.
Many of these were broken by
cbe24710f6.
As it turned out "this may change in the future" was an accurate
prediction. As an aside, I don't like that the README becomes incorrect
on the released version. I should come up with a solution for that.
We're at the point where this can be judged for what it is. We don't
need the design explanation and "please help try it out" bit.
I also want to make sure that anyone who clicks documentation from
crates.io has an easy way to reach the getting started guide.
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
I'm starting to see the lines where I think I'll want to break out
another library, where one is responsible for query building and
database interactions, with the other responsible for removing common
boilerplate.
I think this method might be too broad, as it'll introduce problems if
you have a race condition of two things trying to set `updated_at`. I'm
also not sure if it'll be a problem though, since if you have forms or
an API, you'll have a struct that doesn't have timestamps on it.
There might be another helper function in there, called `update_with`
which uses another struct to update the fields. That said, I'm not sure
why you'd build the struct to represent the whole record with bad data.
Maybe this whole mutable pointer thing is actually just not helpful. I
need to think about it, and try using this API a bit. Potential
additions/changes
`update_with`:
```rust
impl User {
pub fn update_with<T>(&mut self, connection: &Connection, changes: T)
-> QueryResult<()> where
T: AsChangeset,
T::Changeset: Changeset<Target=users>,
{
*self = {
let command = update(users.filter(id.eq(self.id))).set(&changes);
try!(connection.query_one(command)).unwrap()
}
}
}
```
`save_changes` returns new model:
```rust
impl EditProfileForm {
pub fn save_changes<T>(&self, connection: &Connection) -> T where
T: Queriable<UpdateStatement<users, Self::Changeset>::SqlType>,
{
let command = update(users.filter(id.eq(self.id))).set(&self);
try!(connection.query_one(command)).unwrap()
}
}
```
I've opted to never generate code that changes the primary key of a
record. If you *really* want to do that in some scenario, you can do it
manually. This code will need to be updated at some point to deal with
composite primary keys.
Fixes#12.
I've found that having this name conflict with Prelude has been annoying
in practice, which is why I was referring to it as `DbResult` in the
docs. Since I'm already using that name for another type (and this has
resulted in confusion), I went with `QueryResult` for this.
Fixes#21.
