-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Testing exact expiry #38
Conversation
Hi! Thanks for your contribution. The issue we wrote was not super clear, sorry for that. We said that the With that field in place the Some notes:
pub struct Transfer {
/// ID of the transfer
pub idx: i32,
/// Timestamp of the transfer creation
pub created_at: i64,
/// Timestamp of the transfer last update
pub updated_at: i64,
/// Status of the transfer
pub status: TransferStatus,
/// Amount in RGB unit (not considering precision)
pub amount: u64,
/// Type of the transfer
pub kind: TransferKind,
/// ID of the Bitcoin transaction anchoring the transfer
pub txid: Option<String>,
/// Recipient ID (blinded UTXO or Bitcoin script) of an incoming transfer
pub recipient_id: Option<String>,
/// UTXO of an incoming transfer
pub receive_utxo: Option<Outpoint>,
/// Change UTXO of an outgoing transfer
pub change_utxo: Option<Outpoint>,
- /// Expiration of the transfer
- pub expiration: Option<i64>,
+ /// Expiration of the transfer and whether it should be exact
+ pub expiration: Option<(i64, bool)>,
/// Transport endpoints for the transfer
pub transport_endpoints: Vec<TransferTransportEndpoint>,
}
If you find changing the DB too complex or don't want to install the necessary tools, don't worry, just let us know and we can prepare a commit with that change and you can continue the rest of the task on top of that commit. Also, since we are preparing a backwards incompatible release (0.3.0), instead of generating a new migration file, you could also change the existing one ( manager
.create_table(
Table::create()
.table(BatchTransfer::Table)
.if_not_exists()
[...]
.col(ColumnDef::new(BatchTransfer::Expiration).big_unsigned())
+ .col(ColumnDef::new(BatchTransfer::ExactExpiry).boolean()) and a field to the #[derive(DeriveIden)]
pub enum BatchTransfer {
Table,
Idx,
Txid,
Status,
CreatedAt,
UpdatedAt,
Expiration,
+ ExactExpiry,
MinConfirmations,
} By doing so you will not need to call the sea-orm-cli Note: as you see the new parameter is nullable, because when the expiration will be null the |
Hi @zoedberg ! thanks for your time spent to answer to my noob tentative. I supposed that I was missing some points, and you explained me really well what is the needing of the issue. If no some smarter guy ( or you ) create the PR before I can dig a little bit inside your suggestion I will try to update my PR to get it merged. I am still at the beginning of my study or RGB and I stumbled upon these issues that seems quite affordable for me, also because of Rust. I am working with another guy on Mostro and learning more about bitcoin and Rust, but I really think RGB is a real nice improvement for bitcoin in case of success...so learning a bit of it for me could be a great achievement! Hope I can update this PR with your suggestions asap! |
We are happy to wait for you. If you don't complete the task in time for the 0.3.0 don't worry, we'll do also a 0.4.0 once RGB 0.11 will be ready. Thanks again |
You're welcome! By the way I think that we are from the same region... ;) |
Hi @zoedberg ! still alive... I was starting back for my second shot using your precious advices....one thing... pub struct Transfer {
/// ID of the transfer
pub idx: i32,
/// Timestamp of the transfer creation
pub created_at: i64,
/// Timestamp of the transfer last update
pub updated_at: i64,
/// Status of the transfer
pub status: TransferStatus,
/// Amount in RGB unit (not considering precision)
pub amount: u64,
/// Type of the transfer
pub kind: TransferKind,
/// ID of the Bitcoin transaction anchoring the transfer
pub txid: Option<String>,
/// Recipient ID (blinded UTXO or Bitcoin script) of an incoming transfer
pub recipient_id: Option<String>,
/// UTXO of an incoming transfer
pub receive_utxo: Option<Outpoint>,
/// Change UTXO of an outgoing transfer
pub change_utxo: Option<Outpoint>,
/// Expiration of the transfer
pub expiration: Option<i64>,
/// Expiration of the transfer and whether it should be exact
pub expiration: Option<(i64, bool)>, // Added bool here!
/// Transport endpoints for the transfer
pub transport_endpoints: Vec<TransferTransportEndpoint>,
} This is crystal clear, but...after compiler error this lead to a modification to this struct below: #[derive(Debug)]
pub(crate) struct TransferData {
pub(crate) kind: TransferKind,
pub(crate) status: TransferStatus,
pub(crate) txid: Option<String>,
pub(crate) receive_utxo: Option<Outpoint>,
pub(crate) change_utxo: Option<Outpoint>,
pub(crate) created_at: i64,
pub(crate) updated_at: i64,
pub(crate) expiration: Option<(i64, bool)>, // Added bool here!
} and this lead to modify this... #[derive(Clone, Debug, PartialEq, DeriveModel, DeriveActiveModel, Eq)]
pub struct Model {
pub idx: i32,
pub txid: Option<String>,
pub status: TransferStatus,
pub created_at: i64,
pub updated_at: i64,
pub expiration: Option<(i64, bool)>, // Added bool here!
pub min_confirmations: u8,
} Resulting in Rust telling me this... ....
error[E0277]: the trait bound `sea_orm::Value: From<(i64, bool)>` is not satisfied
--> src/database/entities/batch_transfer.rs:16:48
|
16 | #[derive(Clone, Debug, PartialEq, DeriveModel, DeriveActiveModel, Eq)]
| ^^^^^^^^^^^^^^^^^ the trait `From<(i64, bool)>` is not implemented for `sea_orm::Value`
|
= help: the following other types implement trait `From<T>`:
<sea_orm::Value as From<&[u8]>>
<sea_orm::Value as From<&std::string::String>>
<sea_orm::Value as From<&str>>
<sea_orm::Value as From<Cow<'_, str>>>
<sea_orm::Value as From<JsonValue>>
<sea_orm::Value as From<OffsetDateTime>>
<sea_orm::Value as From<PrimitiveDateTime>>
<sea_orm::Value as From<Vec<T>>>
and 30 others
= note: required for `(i64, bool)` to implement `Into<sea_orm::Value>`
= note: required for `sea_orm::Value` to implement `From<std::option::Option<(i64, bool)>>`
= note: 1 redundant requirement hidden
= note: required for `std::option::Option<(i64, bool)>` to implement `Into<sea_orm::Value>`
note: required by a bound in `ActiveValue`
--> /home/lupin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/sea-orm-0.12.8/src/entity/active_model.rs:41:8
|
39 | pub enum ActiveValue<V>
| ----------- required by a bound in this enum
40 | where
41 | V: Into<Value>,
| ^^^^^^^^^^^ required by this bound in `ActiveValue`
= note: this error originates in the derive macro `DeriveActiveModel` (in Nightly builds, run with -Z macro-backtrace for more info) In my undestanding there is a missing pub struct Transfer {
/// ID of the transfer
pub idx: i32,
/// Timestamp of the transfer creation
pub created_at: i64,
/// Timestamp of the transfer last update
pub updated_at: i64,
/// Status of the transfer
pub status: TransferStatus,
/// Amount in RGB unit (not considering precision)
pub amount: u64,
/// Type of the transfer
pub kind: TransferKind,
/// ID of the Bitcoin transaction anchoring the transfer
pub txid: Option<String>,
/// Recipient ID (blinded UTXO or Bitcoin script) of an incoming transfer
pub recipient_id: Option<String>,
/// UTXO of an incoming transfer
pub receive_utxo: Option<Outpoint>,
/// Change UTXO of an outgoing transfer
pub change_utxo: Option<Outpoint>,
/// Expiration of the transfer
pub expiration: Option<i64>,
/// Expiration of the transfer and whether it should be exact
pub expiration: Option<i64>,
pub exact_expiry: Option<bool>, // Added bool here!
/// Transport endpoints for the transfer
pub transport_endpoints: Vec<TransferTransportEndpoint>,
} This should make Rust happy, but as I told you sorry if am not on the right path... Waiting for your opinion! |
Hi @arkanoider! You shouldn't manually edit the By editing the pub expiration: Option<(i64, bool)>, // Added bool here! Because databases don't support tuples. I hope you'll find my explanation helpful and clear enough, otherwise don't hesitate to ask for more clarification. |
Yep! Sounds clear...will try another shot asap. |
Hi @zoedberg , going on in my spare time...first of all have a nice Xmas!! 🎄 🎅 Will let one of my thought here while reading RGB specs and trying to learn more. pub expiration: Option<(i64, bool)> correlated to this the pub struct Model {
pub idx: i32,
pub txid: Option<String>,
pub status: TransferStatus,
pub created_at: i64,
pub updated_at: i64,
pub expiration: Option<i64>,
pub exact_expiry: Option<bool>,
pub min_confirmations: u8,
} A doubt about a cosmetics, if we use the tuple in
pub expiration: (Option<i64>, Option<bool>) let me know your thoughts... |
Hi @arkanoider,
I assume you are referring to the In the first answer I gave to this PR, I've asked to change the - /// Expiration of the transfer
- pub expiration: Option<i64>,
+ /// Expiration of the transfer and whether it should be exact
+ pub expiration: Option<(i64, bool)>, If I understood correctly you are asking if it's possible to change that field like so: - /// Expiration of the transfer
- pub expiration: Option<i64>,
+ /// Expiration of the transfer and whether it should be exact
+ pub expiration: (Option<i64>, Option<bool>), If that's the proposal, I don't agree with it, because, as I previosly said:
This means that it's impossible to have the The only possible combinations are:
The conversion from the 2 structures ( - expiration: td.expiration,
+ expiration: td.expiration.map(|e| Some((e, tx.exact_expiry.unwrap()))), It will be the developer's reponsibility to never insert into the DB a transfer that has an expiration set and an exact_expiry unset. |
Hì @zoedberg , hope you enjoyed your holiday and had a nice start for 2024! Yes in my mind i was thinkin what you correctly understood and it's clear why is not the right solution. |
Hi @arkanoider, |
Hi @zoedberg sorry for my silence, i had a bad 2024 start for personal issues. I'd like to go on for sure, but I will have my mind back on track i need some more time... |
Sorry to hear that, hope things will get better. Currently we're still waiting for RGB 0.11 to be released, so we're not in a rush. In case we're about to release and this is still incomplete we'll probably make the DB changes and leave you all the rest of the work. |
Hi @zoedberg , if the issue is still open I can try to spend some spare time to retry closing it! Personal issue are going better and also the other lightning project let me some time to study...meanwhile I am still trying to find my way in a bitcoin fulltime job! |
Hi @arkanoider! I'm happy to hear that things are going better for you! I think you'll have the time to tackle this |
Thanks @zoedberg , will rewind my mind on it reading bsck the conversation with and will try to implement something! |
Hi,
pardon my noobness first of all.
Was trying to learn and contribute: this is what could be a starting point for issue #37
Let me know how far I am from the right idea.