12.md (3148B)
1 # #12 Add support for shared global state (similar to Actix's web::Data) 2 3 - **State:** open 4 - **Author:** @donicrosby 5 - **Created:** 2022-03-12T06:12:42Z 6 - **Labels:** enhancement 7 - **Assignees:** @MTRNord 8 9 --- 10 11 I've been working on a bot that has some commands that requires a database connection in order to hold some state across restarts. 12 13 While having the config being passed is fine for stateless bots. Anything that would require a long running connection it wouldn't be efficient to connect to the database every single message. It would be a huge improvement if there was a way to have a single state store that is stood up at startup that can be accessed by all of the commands. 14 15 The current config type must have serialize and deserialize which doesn't work for something like a DB without a huge hack of making a custom deserializer that stands up the DB connection to be stored in the config (if that's even possible) 16 17 18 ## Comments 19 20 ### @MTRNord — 2022-03-12T14:39:26Z 21 22 Hm due to the macro currently used this seems like it is quite a lot harder to do as generics wouldnt work as wanted. I am currently trying to understand how actix solved this, as it seems non trivial. 23 24 ### @MTRNord — 2022-03-12T14:40:05Z 25 26 As `Data<Config<'a>>` in the command handler would conflict with `Data<T>` in the macro 27 28 ### @MTRNord — 2022-03-12T14:42:43Z 29 30 To be exact this is the issue the macro currently faces: 31 32 ``` 33 error[E0308]: mismatched types 34 --> example-bot\src\commands\mod.rs:7:1 35 | 36 7 | #[command_generate(bot_name = "Example", description = "This bot prints hello!")] 37 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `config::Config`, found type parameter `T` 38 | 39 = note: expected struct `mrsbfh::utils::Data<config::Config<'_>>` 40 found struct `mrsbfh::utils::Data<T>` 41 = note: this error originates in the attribute macro `command_generate` (in Nightly builds, run with -Z macro-backtrace for more info) 42 ``` 43 44 ### @MTRNord — 2022-03-12T14:45:50Z 45 46 It seems we would need something like this https://docs.rs/actix-web/latest/src/actix_web/handler.rs.html#124-153 But that seems restricting. I will check how axum does data passing. Maybe that has a nicer solution 47 48 ### @MTRNord — 2022-03-12T14:50:25Z 49 50 It seems the best would be to use a trait approach, where commands implement a trait. Instead of using the proc macro. 51 52 ### @donicrosby — 2022-03-12T15:06:10Z 53 54 My only issue with that is it would break backwards compatibility, but we are still v0 😁 55 56 ### @MTRNord — 2022-03-12T15:07:39Z 57 58 > My only issue with that is it would break backwards compatibility, but we are still v0 😁 59 60 I dont think I can not break that while implementing this. But I will try to make it non breaking. Also I likely go more for the way axum does it then actix. As it seems easier to implement :) 61 62 ### @MTRNord — 2022-03-12T16:11:54Z 63 64 Also I am trying to still keep the macro and use the traits internally. But the handlers probably will change and possibly also how you init it. But I am still in the experimentation phase and hope to later share a first working iteration. 65