infer_schema! fails for boolean/bool

[iqualfragile]

i get

src/schema.rs:1:1: 1:40 error: Unsupported type: boolean
src/schema.rs:1 infer_schema!(dotenv!("DATABASE_URL"));

or

src/schema.rs:1:1: 1:40 error: Unsupported type: bool
src/schema.rs:1 infer_schema!(dotenv!("DATABASE_URL"));

im using rust nightly 2016-04-09 and diesel 0.6.1 with sqlite enabled
cargo.toml look like this:

[dependencies]
diesel = "0.6.1"
diesel_codegen = { version = "0.6.1", default-features = false, features = ["nightly", "sqlite"] }
dotenv = "0.8.0"
dotenv_macros = "0.8.0"

my crete table statement is:

create table messages (
        hash blob PRIMARY KEY,
        head BOOL,
        content blob not NULL
);

my model is:

#[derive(Debug,Clone)]
pub struct Hash(pub [u8;32]);

#[derive(Queryable,Debug)]
pub struct Messages {
    pub hash: Hash,
    pub head: bool,
    pub content: Vec<u8>,
}

[sgrif]

Can you try pointing at master? This should have been resolved by ccad151, which will be released later this week.

[iqualfragile]

damn, second fixed bug in diesel i run in today.

[sgrif]

Sorry! I've been moving to another country for the last 2 weeks so I
haven't had time to finish the release. 😔

On Wed, May 11, 2016, 12:32 PM iqualfragile notifications@github.com
wrote:

damn, second fixed bug in diesel i run in today.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#322 (comment)

[iqualfragile]

btw on the embracing sqlite philosophy of untyped sql: i really really don't think thats a good idea, i would just handle it as if the type definitions would be definitive, just like postgress does. there is not really a good usecase for storing different types into the same collumn anyways.
just fail with a good error message if someone put stupid values into the db.

[sgrif]

Yeah, that's likely the direction we'll continue with -- just means that
we'll be chasing edge cases for a while

On Wed, May 11, 2016, 12:35 PM iqualfragile notifications@github.com
wrote:

btw on the embracing sqlite philosophy of untyped sql: i really really
don't think thats a good idea, i would just handle it as if the type
definitions would be definitive, just like postgress does. there is not
really a good usecase for storing different types into the same collumn
anyways.
just fail with a good error message if someone put stupid values into the
db.

—
You are receiving this because you modified the open/close state.

Reply to this email directly or view it on GitHub
#322 (comment)