@JonasCir made a great refactoring🎉 Let's update all the generation methods.

Example:

Old

create_entity https://github.com/EpicsDAO/zapp/blob/main/src/g/entity.rs#L13

Good create_migration https://github.com/EpicsDAO/zapp/blob/main/src/g/migration.rs#L16

Currently, async/await is used all over the place, however, it does not provide any advantage b/c we do not submit any task to an executor or used any concurrency.

I argue that we should selectively re-introduce it properly in parts where it actually makes sense.

You can refer to this resource to learn more.

Hey, this PR is a little bit bigger:

• it splits the generation into its four parts: entity, mutation, graphql mutation, graphql query.
• Each part has a function which takes care of file generation and registration to the corresponding mod.rs
• Log output has been clarified
• Most importantly: --path can now passed to the generation subcommand
• ... which allows us to run integration tests against the g module now :)

This way, you can rest assured that my refactoring does not break the generated files :smile:

Hi there, thank you for creating this project, it looks super useful!

While going through the code generation done in g, I noticed that the Rust code generation is done through plain string formatting. I also worked on a small project where I needed to generate Rust code and I resorted to this approach at first as well. However, I quickly ran into problems like code generation being dependent on conditionals quickly resulting in annoying string concatenations.

I decided to use the popular quote library to template Rust code in a clean manner, making my life a lot easier and the code cleaner to read (I also used prettyplease to auto-format the generated code).

Maybe this is helpful, but feel free to close if this project goes with the format approach.

My project is here for reference: https://github.com/JonasCir/java2rs

zapp new downloads the initial file from Google Cloud Storage at this moment.

https://github.com/EpicsDAO/zapp/blob/5d9f951f8953b62dc5b57d6ca47966e9d00d2198/src/init/process.rs#L126

This initial folder is just 23KB. I want to have it in the local machine when cargo install zapp.

Fixes #6

@POPPIN-FUMI We now have a proper new command. PR features:

1. No downloading of templates (you can remove the old Google storage now)
2. The files we create are now stored as templates. We can easily tweak/improve them over time to our liking
3. Generation of the migration is programmatically done through sea-orm-cli directly
4. Integration testing has been become super convenient b/c of assert_directory_equality
5. I cut down the files and content of the emitted to the bare minimum. I'm not a fan of feature-creep, if we notice that something is missing, we can simply add/improve it.

Please note that generation (which would be the next step after running zapp new) is currently broken. This is due to the fact that a) the code we generate is not compatible with the sea-orm version we are pinning and b) sea-orm is migration based, so we need to switch this (gone file an issue about that later).

Currently, running zapp docker psql throws an error. This is because the gcp config is parsed (and not present if you do not create it by hand). However, since this is creates a purely local container, forcing the devs to create such a config does not make sense.

fixes #10

all generation types (migration, entity, etc) are now in their dedicated module which is again split into creation and registration (i.e., write modules to mod.rs).

Much cleaner now :rocket:

pub use sea_orm_migration::prelude::*;

// Load module here;

pub struct Migrator;

#[async_trait::async_trait]
impl MigratorTrait for Migrator {
    fn migrations() -> Vec<Box<dyn MigrationTrait>> {
        vec![
            // Define migration file here;
        ]
    }
}

Not certain how this is supposed to work: We always define the Help variant in commands in src/cli/mod.rs but do not match it in main.rs. I would assume that we can get rid of this variant and just let do clap its magic when an unknown command is encountered.

Probably something along these lines.

Edit: I just found #[clap(arg_required_else_help = true)]. Edit 2: we should bump clap to the most recent version

General

seo-orm in general uses a migration based approach, which means that migrations provided by the developer are used to generate the entity code.

Since we are completely based on sea-orm we should follow this approach.

Proposed change

Introduce the following new gen commands:

1. gen migration: Use sea-orm-cli migrate generate my_new_table -u programmatically
2. gen model: Use sea-orm-cli migrate fresh programatically (we probably want a dedicated DB for generation and one DB for the user to tests its app)
3. gen graphql: Use templating of GraphQL, later switch to Seaography

Currently, we abbreviate the generation command with g which is

1. not intuitive
2. the only command we abbreviate with one letter
3. reads strange

I think we should be consistent and rename the command the gen throughout the code base,

I notice that we invoke binaries all over the place. Get rid of the invocation and use libraries instead.

While this is a general problem, let's focus on the generation submodule first.

There is an ongoing discussion in sea-orm how to use it functionally directly/programmatically.

https://github.com/SeaQL/sea-orm/discussions/1036 https://github.com/SeaQL/sea-orm/issues/1047