Change `use crate::diesel::*;` import to be more specific and not require `crate::`

[jjangga0214]

dsync/test/simple_table/models/todos/generated.rs

Line 3 in 007ace8

use crate::diesel::*;

dsync generates use crate::diesel::*;.

But I think it actually should be use diesel::*;.

diesel is an external crate, which is not declared from the root of a user's project.

[hasezoey]

i guess that is true, but currently it is somewhat expected you do a pub use diesel; in the entry-point of your crate (like lib.rs)

[Wulf]

Good catch @jjangga0214! @hasezoey is right, we often include extern crate diesel or a use statement in our entry points. I think we can safely remove the crate:: prefix :)

[hasezoey]

Re-opening the issue because of #116, this will need a better solution than just replacing the wildcard import (with some more specific import or a alias)

[hasezoey]

i am thinking of fixing this, but there are 2 ways:

1: with a alias (if yes, what alias)

use diesel as D;

#[derive(Debug, Clone, serde::Serialize, serde::Deserialize, D::Queryable, D::Selectable, D::QueryableByName)]
#[D::diesel(table_name=todos, primary_key(id))]
pub struct Todos {
    pub id: i32,
    pub unsigned: u32,
    pub unsigned_nullable: Option<u32>,
    pub text: String,
    pub completed: bool,
    pub type_: String,
    pub created_at: chrono::DateTime<chrono::Utc>,
    pub updated_at: chrono::DateTime<chrono::Utc>,
}

or 2: directly:

#[derive(Debug, Clone, serde::Serialize, serde::Deserialize, diesel::Queryable, diesel::Selectable, diesel::QueryableByName)]
#[diesel::diesel(table_name=todos, primary_key(id))]
pub struct Todos {
    pub id: i32,
    pub unsigned: u32,
    pub unsigned_nullable: Option<u32>,
    pub text: String,
    pub completed: bool,
    pub type_: String,
    pub created_at: chrono::DateTime<chrono::Utc>,
    pub updated_at: chrono::DateTime<chrono::Utc>,
}

which would be better?

(using direct imports like use diesel::{Queryable} is not possible because that may conflict with user names and using use diesel::{Queryable as DQueryable} or similar is quite a lot of clutter than the other options)

i personally think using diesel:: everytime adds quite the clutter

@Wulf what do you think would be better?

[jjangga0214]

IMHO, the latter is better :)

[Wulf]

hey @hasezoey thanks for investigating and thinking of solutions. Again, sorry for the late reply, I've been in the middle of a move!

Let's go with diesel::, it's copy-pastable and less ambiguous. I think it'll make the dsync code easier to maintain as well (we won't need to manage aliasing)

[hasezoey]

created #122 which changes most things to use the diesel:: prefix, but this does not completely solve this issue yet because of the diesel trait imports, where i am not sure which are fully required and would like to wait for #114 and add additional tests as pointed out by #119

PS: also changed the issue title to better reflect what this is about