New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug at using tables with more than 16 fields #477

Closed
tredoe opened this Issue Oct 13, 2016 · 11 comments

Comments

Projects
None yet
5 participants
@tredoe

tredoe commented Oct 13, 2016

There is a little bug when you have a table with more than 16 fields.
To check it, I use this table:

CREATE TABLE foo (
    id INT PRIMARY KEY,

    foo01 TEXT,
    foo02 TEXT,
    foo03 TEXT,
    foo04 TEXT,
    foo05 TEXT,
    foo06 TEXT,
    foo07 TEXT,
    foo08 TEXT,
    foo09 TEXT,
    foo10 TEXT,
    foo11 TEXT,
    foo12 TEXT,
    foo13 TEXT,
    foo14 TEXT,
    --foo15 TEXT,
    foo16 TEXT
);
#[derive(Queryable)]
pub struct Foo {
    pub id: i32,

    pub foo01: String,
    pub foo02: String,
    pub foo03: String,
    pub foo04: String,
    pub foo05: String,
    pub foo06: String,
    pub foo07: String,
    pub foo08: String,
    pub foo09: String,
    pub foo10: String,
    pub foo11: String,
    pub foo12: String,
    pub foo13: String,
    pub foo14: String,
    //pub foo15: String,
    pub foo16: String,
}

And I run the next command

$ dropdb diesel_demo && diesel setup && cargo test

It should be ok. Now, comment out the field 'foo15' and try it again.

@killercup

This comment has been minimized.

Member

killercup commented Oct 13, 2016

What error are you getting? I think you are running into the default column number limitation. The docs for table! (which is also used internally) say:

By default this allows a maximum of 16 columns per table, in order to reduce compilation time. You can increase this limit to 26 by enabling the large-tables feature, or up to 52 by enabling the huge-tables feature. Enabling huge-tables will substantially increase compile times.

Does this work for you when enabling the large-tables feature for Diesel in your Cargo.toml?

@tredoe

This comment has been minimized.

tredoe commented Oct 13, 2016

I'm supposed that is the problem.

What there is to write in Cargo.toml to enable it? I could not find in doc.

@killercup

This comment has been minimized.

Member

killercup commented Oct 13, 2016

What there is to write in Cargo.toml to enable it?

Where you define diesel as a dependency, you can also list the features you want to enable, like so:

[dependencies]
diesel = { version = "0.8", features = ["postgres", "large-tables"] }
@tredoe

This comment has been minimized.

tredoe commented Oct 13, 2016

The error that I get is like

error[E0277]: the trait bound `(...)>` is not satisfied
@tredoe

This comment has been minimized.

tredoe commented Oct 13, 2016

I had in Cargo.toml:

diesel = "^0.8"
diesel_codegen = { version = "^0.8", features = ["postgres"] }
@tredoe

This comment has been minimized.

tredoe commented Oct 13, 2016

It works now using:

diesel = { version = "^0.8", features = ["large-tables"] }
diesel_codegen = { version = "^0.8", features = ["postgres"] }

Thanks!

@killercup

This comment has been minimized.

Member

killercup commented Oct 13, 2016

Great!

@killercup killercup closed this Oct 13, 2016

@lancecarlson

This comment has been minimized.

Contributor

lancecarlson commented Jun 26, 2017

I just ran into this issue and this is ridiculous. Why is there such a thing as "large table support?" Shouldn't it default to any size table you like?

@killercup

This comment has been minimized.

Member

killercup commented Jun 27, 2017

@lancecarlson I understand your frustration, but sadly it's a known limitation right now. In Diesel, but also in Rust itself: Tables are represented as tuples and currently, Rust does not have a way to deal with arbitrarily large tuples.

If you want to know more, have a look at Diesel PR #747, the resulting rust-lang/rfcs#1921 and the newer rust-lang/rfcs#1935.

@mattdeboard

This comment has been minimized.

mattdeboard commented Oct 21, 2017

Actually I guess this answers my other question

@robsaunders

This comment has been minimized.

robsaunders commented Mar 16, 2018

The error for this is so ambiguous it's kind of ridiculous. Hopefully rust improves, removes this limitation for enums, and people stop using huge macros as fundamental functionality in their libraries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment