Support for #[derive(Serialize)]

[9876691]

Would you consider adding the ability to tag the structs you create with #[derive(Serialize)]?

The reason for this is that in a lot of web frameworks you can convert structs to JSON as long as they are tagged with the Serde macro.

For example see how Axum handles it.

https://docs.rs/axum/latest/axum/struct.Json.html

perhaps an argument --derive '#[derive(serve::Serialize)]' or perhaps --struct-prefix

Thanks

[LouisGariepy]

Thank you for this suggestion. I agree, this could be useful.

I moved this feature request to the issue list!

#72

[9876691]

Hi I saw 72 was merged but I can't see how to call it from the command line.

I'm running something like the following in build.rs

fn cornucopia() -> Result<()> {
    // For the sake of simplicity, this example uses the defaults.
    let queries_path = "queries";

    // Again, for simplicity, we generate the module in our project, but
    // we could've also generated it elsewhere if we wanted to.
    // For example, you could make the destination the `target` folder
    // and include the generated file with a `include_str` statement in your project.

    let out_dir = env::var_os("OUT_DIR").unwrap();
    let file_path = Path::new(&out_dir).join("cornucopia.rs");

    let db_url = env::var_os("DATABASE_URL").unwrap();

    // Rerun this build script if the queries or migrations change.
    println!("cargo:rerun-if-changed={queries_path}");

    // Call cornucopia. Use whatever CLI command you need.
    let output = std::process::Command::new("cornucopia")
        .arg("generate")
        .arg("-d")
        .arg(file_path)
        .arg("live")
        .arg("--url")
        .arg(db_url)
        .output()?;

    // If Cornucopia couldn't run properly, try to display the error.
    if !output.status.success() {
        panic!("{}", &std::str::from_utf8(&output.stderr).unwrap());
    }

    Ok(())
}

[LouisGariepy]

Hi @ianpurton!

To be clear, these improvements are not released yet. Until they are, (should be soonish), you'll have to use the main branch to try them out.

Assuming you do have the latest version you simply have to pass the --serialize flag along to the cornucopia command.

    // Call cornucopia. Use whatever CLI command you need.
    let output = std::process::Command::new("cornucopia")
        .arg("generate")
        .arg("-d")
        .arg(file_path)
        .arg("live")
        .arg("--url")
        .arg(db_url)
        .arg("--serialize") //<-- this
        .output()?;

---

Alternatively, cornucopia now also comes with an API, which it makes it a bit nicer for build scripts (among other things). First add it to your Cargo.toml:

[build-dependencies]
cornucopia = "..."

Note that build dependencies, like dev dependencies, won't be included in your binary.

Now, you can replace std::process::Command::new("cornucopia") ... ... ... with

  let settings = CodegenSettings {
      is_async: true,
      derive_ser: true,
  };
  
  cornucopia::generate_live(
      &mut client,
      queries_path,
      migrations_path,
      Some(destination),
      settings
  )
  .unwrap();

[LouisGariepy]

By the way, the crate is moving and improving very fast at the moment, but we'll make sure to release a solid version change guide and collect some feedback before releasing the next version!

[9876691]

This is great thanks.

How are you doing releases at the moment?

I've been using https://www.npmjs.com/package/@semantic-release/npm to automate the whole thing whenever a pull requests hits master.

The github action looks like this https://github.com/purton-tech/cloak/blob/main/.github/workflows/ci.yml#L54

And config would look something like https://github.com/purton-tech/cloak/blob/main/.releaserc.json

Hope this helps.

[LouisGariepy]

Thanks for the tips and the kind words!

For the record, we do follow SemVer for actual releases, but we try to release a new version on a milestone basis, not on a PR basis. This is simply to reduce the amount of maintenance churn during this rapidly evolving phase of the project, and to provide users with meaningful chunks of usability (well-documented and tested, etc) instead of bits and bobs at every release.

Once things settle down, we could switch to a more stable release scheme 😄