< 返回版块

happyending 发表于 2023-12-23 17:52

项目中使用了sqlx,这个包中包含了sqlx::types::BigDecimal 但是不能使用其包中的一些其他枚举,比如ParseBigDecimalError,或者当返回一些依赖库中的类型pub fn sign(&self) -> Sign,业务代码就不能直接比较了

if amount.sign() == num::bigint::Sign::Minues // 报错,Sign是sqlx::types::BigDecimal内部的类型,不能获取到

我不得不引入原始的big decimal,这样子ParseBigDecimalErrorSign都可以导入

use bigdecimal::{ParseBigDecimalError, BigDecimal};
use bigdecimal::num_bigint::Sign;

但是这样子又存在类型互转了,感觉好麻烦,有啥解决办法吗

评论区

写评论
作者 happyending 2023-12-23 21:26

感谢,确实。我重新在Cargo.toml中导入了num-traits这个lib,因为只需要用到from_f32或者to_f32这些trait方法。不导入和sqlx相同版本的bigdecimal是因为使用的时候,ide会提示两个版本的BigDecimal感觉不方便😂。然后相同统一用sqlx::types::BigDecimal

--
👇
苦瓜小仔:

这样子又存在类型互转了,感觉好麻烦

类型并没被转化,你去看源码的话,Sign 被定义在 num_bigint 库,然后在 num::bigintbigdecimal::num_bigint 被重导出,它们底下的 Sign 都是一个东西,所以你可以使用任何一个地方的Sign,只要 Cargo.lock 里 num_bigint 库的版本号一致。

有的库的确会只重导出它需要的类型,像现在 sqlx 没有重导出整个 bigdecimal,的确不方便。办法就是上面说的,在你的依赖中引入那个类型所在的库。

不过,像 bigdecimal 已经是 sqlx 的一个直接依赖,所以当它已经在你的 Cargo.lock 中出现时,它已经变成间接/全局依赖,也就是无论如何都会下载、编译和被使用的依赖,也就是此时你在 Cargo.toml 中引入相同版本的它是免费的。这适用于 num_bigint:它是 Sign 最初被定义的地方,自然也会出现在 Cargo.lock 中,所以引入它也是免费的。

至于如果在某些地方引入同一个依赖,但版本不兼容,那么 Cargo.lock 会出现同一依赖的不同版本,那也没什么担心的,Rust 会处理好不兼容的同一个库 —— 毕竟最终都会经过优化,根本不需要担心重复的代码或者不必要的转化 。

苦瓜小仔 2023-12-23 20:31

这样子又存在类型互转了,感觉好麻烦

类型并没被转化,你去看源码的话,Sign 被定义在 num_bigint 库,然后在 num::bigintbigdecimal::num_bigint 被重导出,它们底下的 Sign 都是一个东西,所以你可以使用任何一个地方的Sign,只要 Cargo.lock 里 num_bigint 库的版本号一致。

有的库的确会只重导出它需要的类型,像现在 sqlx 没有重导出整个 bigdecimal,的确不方便。办法就是上面说的,在你的依赖中引入那个类型所在的库。

不过,像 bigdecimal 已经是 sqlx 的一个直接依赖,所以当它已经在你的 Cargo.lock 中出现时,它已经变成间接/全局依赖,也就是无论如何都会下载、编译和被使用的依赖,也就是此时你在 Cargo.toml 中引入相同版本的它是免费的。这适用于 num_bigint:它是 Sign 最初被定义的地方,自然也会出现在 Cargo.lock 中,所以引入它也是免费的。

至于如果在某些地方引入同一个依赖,但版本不兼容,那么 Cargo.lock 会出现同一依赖的不同版本,那也没什么担心的,Rust 会处理好不兼容的同一个库 —— 毕竟最终都会经过优化,根本不需要担心重复的代码或者不必要的转化 。

1 共 2 条评论, 1 页