thread 'main' panicked at 'Ident cannot be a number; use Literal instead' if enum field include numeric values

[ttys3]

Description

panicked at 'Ident cannot be a number; use Literal instead' if enum field include numeric values

yes, I know. nobody should define a table using enum like this enum('0','1') this is terrible and very bad, but, this is a very old project.

and I just got this problem

Steps to Reproduce

1. create a mysql table with enum which members have numeric values:

CREATE TABLE `num_enum_demo` (
  `id` int unsigned NOT NULL AUTO_INCREMENT,
  `public` enum('0','1') NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

2. run generate

RUST_BACKTRACE=1 sea-orm-cli generate entity -o src/entity -t num_enum_demo

you will got panic:

thread 'main' panicked at 'Ident cannot be a number; use Literal instead', /path-to/8f6827c7555bfaf8/proc-macro2-1.0.38/src/fallback.rs:683:9
stack backtrace:
   0: std::panicking::begin_panic
   1: proc_macro2::fallback::Ident::_new
   2: proc_macro2::Ident::new
   3: quote::__private::mk_ident
   4: sea_orm_codegen::entity::active_enum::ActiveEnum::impl_active_enum
   5: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
   6: sea_orm_codegen::entity::writer::EntityWriter::write_sea_orm_active_enums
   7: sea_orm_codegen::entity::writer::EntityWriter::generate
   8: sea_orm_cli::commands::run_generate_command::{{closure}}
   9: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  10: std::thread::local::LocalKey<T>::with
  11: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  12: async_io::driver::block_on
  13: std::thread::local::LocalKey<T>::with
  14: std::thread::local::LocalKey<T>::with
  15: std::thread::local::LocalKey<T>::with
  16: async_std::task::builder::Builder::blocking
  17: sea_orm_cli::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Expected Behavior

no panic

Actual Behavior

panic

Reproduces How Often

always

Versions

sea-orm-cli 0.7.2

Additional Information

[tyt2y3]

I feel like this is a duplicate issue #579

[ttys3]

yes, the same problem.

good to see already has PR
#588

[tyt2y3]

But actually I am quite hesitant to merge that PR. @ttys3 can you explain the reasoning behind numeric enums?

[ttys3]

@tyt2y3 the table schema is from a very old project, probably at least 10 years ago.

so it is not designed by me. it is just an old mysql db.

I changed the column to public enum('no','yes') NOT NULL DEFAULT 'no'` so the panic is gone.
what I want to say is, if the PR is not going to merge. then maybe we should warn user about this and just skip generate model for the table. a panic will stop all the work and user do not know what happend, a more friendly error message is also required.

in my situation, it figured me a lot of time to find out why this happend.

I use a shell script (in Makefile) to generate each table, so I could find which table caused the panic (which I hope sea-orm-cli will tell me)

	sudo podman exec -ti mysql-server-host sh -c 'mysql -uroot -p$$MYSQL_ROOT_PASSWORD -e "SELECT table_name FROM information_schema.tables WHERE table_schema ='"'"'my-database-name'"'"'\G"' | rg TABLE_NAME | awk -F: '{print $$2}' > /tmp/tables.txt
	for tbl in `cat /tmp/tables.txt`; \
    do \
    echo "generating $$(echo -e $${tbl} | tr -d '[:space:]')"; \
    sea-orm-cli generate entity -t $$(echo -e $${tbl} | tr -d '[:space:]') -o src/entity; \
    done

[tyt2y3]

Actually, this is a good suggestion.
@billy1624 the generator seems to be quite opaque?
I think the general solution is to return a Result everywhere instead of panicking in place and so the parent function can bail with context.
Or a really simple solution ... just add more logs with log::debug! such that users can turn on with RUST_LOG=debug would be a lot more helpful.

[ttys3]

currently the output result of enabling -v, --verbose Show debug messages is too noisy, I tried use it and totally do not know what it means. just endless output something like fetch data from schema table.

I think we need a log level config, instead of put everything to debug log and only have a -v switch
Something like "generating for table xxxx" should be info level, users may happy to see this detail. at leat they know what is doing now.

[billy1624]

Hey @ttys3 & @tyt2y3, thanks for the input! I have consolidated the suggestions into an issue

• [CLI] Show progress when generating entity files #722