Skip to content
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

Adding barrel feature #1573

Merged
merged 69 commits into from
Apr 17, 2018
Merged

Adding barrel feature #1573

merged 69 commits into from
Apr 17, 2018

Conversation

spacekookie
Copy link
Contributor

This is the initial version of integrating barrel into diesel. A few things are still not optimal and I'd like to get some feedback regarding that.

  1. There are some barrel specific functions and structs in the migrations_internal module which are only compiled when using barrel. I would love to keep those parts in the barrel crate but can't because of cyclic dependencies. Is there a different way to solve this? If so, how?

  2. Currently (for testing) the barrel feature is always enabled on diesel. How would I add features = [ "barrel"] to the migration_internals crate, depending on the external flag? Is there a more elegant way of doing this?

  3. Should the code added to diesel_cli be conditionally added with a barrel feature flag too?

Additionally the barrel dependency currently points to git which should be changed once barrel 0.2 is released

.long("type")
.short("t")
.takes_value(true)
.help("Specify the migration type."),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add .possible_values(&["sql", "barrel"]) and .default_value("sql")?

@@ -51,6 +51,13 @@ pub fn build_cli() -> App<'static, 'static> {
for most use cases.",
)
.takes_value(true),
)
.arg(
Arg::with_name("type")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Arg names should be uppercase by convention.

down.write_all(b"-- This file should undo anything in `up.sql`")
.unwrap();
match migration_type {
Some("barrel") => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be #[cfg]d.

barrel_migr.write(b"/// Handle down migrations \n").unwrap();
barrel_migr
.write(b"fn down(migr: &mut Migration) {} \n")
.unwrap();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of this code should live in Barrel, not Diesel.

.unwrap();
}
_ => {
let up_path = migration_dir.join("up.sql");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we pull this out into a function?

@@ -49,6 +58,39 @@ pub fn migration_from(path: PathBuf) -> Result<Box<Migration>, MigrationError> {
}
}

#[cfg(feature = "barrel")]
struct BarrelMigration(PathBuf, String, String, String);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we just move the migration trait from diesel_migrations into diesel so this code can live in Barrel?

Copy link
Member

@sgrif sgrif left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good start, but there's more restructuring to be done. Given that we don't maintain Barrel, I want to have as little Barrel specific code in Diesel as possible.

@sgrif
Copy link
Member

sgrif commented Feb 23, 2018

CI is failing.

@spacekookie
Copy link
Contributor Author

spacekookie commented Feb 24, 2018

Yea, there is a problem with the code I don't know how to solve. I messaged you on gitter about it.

Also, looking at what's failing, it seems to be fine on one of the nightly branches. barrel does currently require nightly until rust#44490 is stabilised.

@sgrif
Copy link
Member

sgrif commented Feb 24, 2018 via email

/// A migration name
#[allow(missing_debug_implementations)]
#[derive(Clone, Copy)]
pub struct MigrationName<'a> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did this need to move?

@@ -19,3 +20,67 @@ pub trait Migration {
None
}
}

/// A migration name
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we document what this actually does rather than just repeating the name of the type?

#[allow(missing_debug_implementations)]
#[derive(Clone, Copy)]
pub struct MigrationName<'a> {
/// Wraps around a migration
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we provide more information than just repeating the type?

pub migration: &'a Migration,
}

/// Get the name of a migration
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we provide more information than just repeating the function/argument names? Maybe at least a usage example?

@spacekookie
Copy link
Contributor Author

That's a fair point, I moved the MigrationName stuff back to migrations_internals. I don't really know what else to document about it. Considering that nothing else in that module is documented I think this should be alright.

@spacekookie
Copy link
Contributor Author

Ping @sgrif it builds now! 🎉 😄

@sgrif
Copy link
Member

sgrif commented Apr 17, 2018 via email

@killercup killercup merged commit fb1e61b into diesel-rs:master Apr 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants