Problematic update

[petar-dambovaliev]

Hello,

I have an application that was locked onto a git commit of rocket.
I am updating it to the latest release on crates.io
I had to refactor a whole lotta of code.
Currently, i have a problem with the database fairing, whatever that means.
I assume that is dependency injection.
I get the error "missing database fairing for MyDB".
This shouldn't happen because i am actually adding it to the app, as you can see from the code below.

#[database("datatypes")]
pub struct MyDB(Client);

    let rocket = rocket::custom(config)
        .attach(MyDB::fairing())

//here is the error
MyDB::get_one(&rocket)

I also can see this when the application is starting.

📡 Fairings:
   >> 'datatypes' Database Pool (ignite)

[p-fruck]

You are referring to rocket v0.5-rc.1 if I understood correctly. Do you have a Rocket.toml in your project? As described here, you should create a Rocket.toml with the following content:

[global.databases]
datatypes={url="mysql://<user>:<password>@<host>/<database>"}

Note that this is an example for mysql only, for different types of databases you might have to adapt the url string. You can also define the database url as a environment variable, e.g.

ROCKET_DATABASES={datatypes={url="mysql://<user>:<password>@<host>/<database>"}}

[petar-dambovaliev]

I do have this in the Rocket.toml

[global.databases]
datatypes = {url = "postgres://postgres:postgres@localhost/name", pool_size = 5}

If the object is missing because it couldn't be constructed, i would assume that it would give me another error.

I noticed that the application is working.
Only the tests which use the rocket instance are failing in this way.

[ELD]

Could you post up:

1. The function where you start up the Rocket instance (with anything sensitive redacted) and the imports in that file
2. The actual compiler error you're receiving

From first glance, it looks like you don't have a #[derive(Database)] on the MyDB type. I can't be certain, though, because I don't have enough context about what your code currently looks like.

[petar-dambovaliev]

Ohh, thanks for the tip.
It breaks our code a lot though.
It took me thousands of changes (1 week) to arrive to this point.
And now, i need to redesign all of our tests.
It's really unfortunate.

[ELD]

It sounds like the commit you were on before your updated was prior to introducing type states. That's going to change a fair amount of code since Build, Ignite, and Orbit mean different things. The Rocket type docs should help with the type state changes.

[petar-dambovaliev]

https://github.com/SergioBenitez/Rocket?branch=master#8d4d01106e2e10b08100805d40bfa19a7357e900
We were on this commit

[petar-dambovaliev]

Ah, I see now.

So, the issue appears to be that you're returning a Rocket<Build>. As per the docs, fairings don't attach until Rocket<Ignite> (https://api.rocket.rs/master/rocket/struct.Rocket.html#method.ignite). If you look at the traits for connection pools, you'll find that the fairing returned are on_ignite fairings (https://github.com/SergioBenitez/Rocket/blob/master/contrib/sync_db_pools/lib/src/connection.rs#L71-L94), so you have to call ignite on the Rocket<Build> in order to force fairing attachment.

So, if you change your test code to do:

...
let r = webserver(None).ignite().await.unwrap();
let typesdb = DataTypesDb::get_one(&r).await.unwrap();
...

... You should be good to go.

Why does the library macro now then not implement the type requirement of Rocket<Ignite> or a trait that allows for fairings ?
Here is the generated function signature.

 pub async fn get_one<P>(
            __rocket: &::rocket_sync_db_pools::rocket::Rocket<P>,
        ) -> Option<Self>
        where
            P: ::rocket_sync_db_pools::rocket::Phase,

The problem would be spotted immediately when these type requirements are added.

[ELD]

That's a fair question. I don't know.