Description

The intuitive, obvious way to do a multi-record insert (foo::Entity::insert_many(iter).exec(...)) provides highly surprising behavior if the iterator passed to it is empty (inserting a single DEFAULT record instead of inserting nothing).

#1708 added .on_empty_do_nothing() to work around that problem and enable the more predictable behavior of an empty iterator resulting in nothing being inserted, but it seems quite regrettable (and highly counterintuitive IMO) for that to be opt-in instead of the default; without it most insert_many() calls likely end up as time bombs just waiting for an empty iterator to cause havoc.

I suppose it would technically be a backwards-incompatible change to make it the default and hence unfit for a minor or patch release, but it's too bad the 0.x->1.0 release didn't take the opportunity to make that change. Could it please be added to the agenda for a 2.0 release?

Versions

$ cargo tree | grep sea-
├── sea-orm v1.1.6
│   ├── sea-orm-macros v1.1.6 (proc-macro)
│   │   ├── sea-bae v0.2.1 (proc-macro)
│   ├── sea-query v0.32.2
│   │   ├── sea-query-derive v0.4.2 (proc-macro)
│   ├── sea-query-binder v0.7.0
│   │   ├── sea-query v0.32.2 (*)
├── sea-orm-migration v1.1.6
│   ├── sea-orm v1.1.6 (*)
│   ├── sea-orm-cli v1.1.6
│   │   ├── sea-schema v0.16.1
│   │   │   ├── sea-query v0.32.2 (*)
│   │   │   └── sea-schema-derive v0.3.0 (proc-macro)
│   ├── sea-schema v0.16.1 (*)
├── sea-query v0.32.2 (*)

DB: Postgres 16.4
OS: Linux