* sea-orm-cli Implement derives & attributes parameters for entity generation (#1124)
* implement derives & attributes for cli
* fmt and clippy fix
* use comma delimiter for attributes arg
* Update help message use `'` instead of `"` to quote
* Refactoring
* remove unnecessary cloning
Co-authored-by: Billy Chan <ccw.billy.123@gmail.com>
* [CLI] generate model with extra derives and attributes
* clippy
Co-authored-by: Isaiah Gamble <77396670+tsar-boomba@users.noreply.github.com>
* Add serde skip options for hidden columns to the CLI (#1171)
* Add serde skip options for hidden columns to the CLI
* Resolve rustfmt and clippy issues
* Use SerdeDeriveOptions instead of WithSerde in tests
* Resolve upstream conflict
Co-authored-by: Billy Chan <ccw.billy.123@gmail.com>
* [CLI] serde_skip_hidden_column
* clippy
* clippy
Co-authored-by: Jacob Trueb <jtrueb@northwestern.edu>
* extracting get_column_def from create_table_from_entity to make it available for database upgrade processes.
* Align code example formatting
* Converting the foreign key related code from create_table_from_entity into From<RelationDef> implementations to make its usage easier in different context, like updating a database.
* Refactor
* Fixup
Co-authored-by: Billy Chan <ccw.billy.123@gmail.com>
Mark transaction as closed *only* after commit/rollback succeeds.
Previously, `open` on the transaction would be set to `false` prior to attempting
to commit or rollback the transaction. When the operation failed, for example, due
to a serialization failure with a serializable isolation level, this would leave
the transaction in an inconsistent state, where it thought it was closed but really
it was still open. The connection would then be returned to the connection pool with
a transaction depth of 1, causing a savepoint to be erroneously created the next time
a transaction was created for the connection.
By waiting to set `open` to `false` until the commit/rollback succeeds, a failure
to do either will result in us correctly rolling back the transaction when dropping
it, ensuring that the connection is returned to the pool with a transaction depth
of 0. Note that this is consistent with how `sqlx` handles transactions.
We attempted to write a test, but had a very difficult time forcing postgres to fail
to commit a transaction. We found that it would block our requests instead when creating
conflicting updates, and we couldn't find any information about when it blocks vs when
transaction commits fail.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Nathan Sobo <nathan@zed.dev>
