Hitting 'negative last_insert_rowid' panic with Sqlite

[nitnelave]

Description

I have a table with a primary ID that is a hash, stored as a signed integer (since unsigned 64 bit is not supported). Auto-increment is turned off for that table.
When storing a new element, if the hash as signed is negative, then sea-orm panics on that line: https://github.com/SeaQL/sea-orm/blob/master/src/executor/execute.rs#L43

Steps to Reproduce

• Create an SQlite table with an i64 primary key: https://github.com/nitnelave/lldap/blob/c64d32e2c0cc698c61ca40e8364ab0cd7934cd46/server/src/domain/model/jwt_refresh_storage.rs#L12
• Insert a negative value.

Expected Behavior

Since auto-increment is turned off for that table, last_insert_id should probably not be called to avoid a panic.

Actual Behavior

Panic.

Reproduces How Often

Always.

Versions

Using sea-orm 0.10.3 (no other version override). Running on alpine, using the bundled Sqlite.

Additional Information

The query, for reference: https://github.com/nitnelave/lldap/blob/c64d32e2c0cc698c61ca40e8364ab0cd7934cd46/server/src/infra/sql_backend_handler.rs#L49

[nitnelave]

For reference, the Sqlite schema info for the table:

sqlite> pragma table_info(jwt_refresh_storage);
0|refresh_token_hash|INTEGER|1||1
1|user_id|text(255)|1||0
2|expiry_date|TEXT|1||0

[billy1624]

Hey @nitnelave, interesting! I never thought anyone could hit this panic.

You're right, since we have auto increment disabled, the primary key value should be given and invocation of last_insert_id() method can be avoided.

sea-orm/src/executor/insert.rs

Lines 128 to 161 in d80e61e

	#[allow(unused_variables, unreachable_code)]
	async fn exec_insert<A, C>(
	primary_key: Option<ValueTuple>,
	statement: Statement,
	db: &C,
	) -> Result<InsertResult<A>, DbErr>
	where
	C: ConnectionTrait,
	A: ActiveModelTrait,
	{
	type PrimaryKey<A> = <<A as ActiveModelTrait>::Entity as EntityTrait>::PrimaryKey;
	type ValueTypeOf<A> = <PrimaryKey<A> as PrimaryKeyTrait>::ValueType;
	let last_insert_id_opt = match db.support_returning() {
	true => {
	let cols = PrimaryKey::<A>::iter()
	.map(|col| col.to_string())
	.collect::<Vec<_>>();
	let res = db.query_one(statement).await?.unwrap();
	res.try_get_many("", cols.as_ref()).ok()
	}
	false => {
	let last_insert_id = db.execute(statement).await?.last_insert_id();
	ValueTypeOf::<A>::try_from_u64(last_insert_id).ok()
	}
	};
	let last_insert_id = match primary_key {
	Some(value_tuple) => FromValueTuple::from_value_tuple(value_tuple),
	None => match last_insert_id_opt {
	Some(last_insert_id) => last_insert_id,
	None => return Err(DbErr::UnpackInsertId),
	},
	};
	Ok(InsertResult { last_insert_id })
	}

I'll draft a PR tomorrow morning :)

[nitnelave]

Small style note: a match for a boolean? Why not a if-else block?
Also, the nested match just below can probably be re-written as a match (last_insert_id, last_insert_id_opt) to reduce nesting.