Really great video! Diesel always seemed very complicated, but your explanations and code were very good. As a suggestion for future video, maybe SQLX can provide a good comparison ground for those who are deciding which one to use. Also, I was wondering if there's an ORM that has async support. That can also make a nice comparison video.
Please keep in mind, you can use SQLx and a repository pattern (or something alike) to abstract away your sql. As powerful ORMs are to prototype and for simple CRUD, as big of a pain in the back they can become when you introduce complexity!
Thanks for summarizing [diesel] and how it was designed. I was about to use use rust to translate sql files. [diesel] is very complex and time consuming. You have to be a seasoned programming veteran to use this. I wrote script for making a cargo project, just in case I need to use it in the future. But man there is no way a regular programmer is going to get this. I am shocked that diesel only supports postgresql, mysql, and sqlite. I was looking for rust database drivers for mission critical million dollar businesses which usually only use oracle , sybase, db2, postgresql , mssql, and (sometimes) terrcotta+snowflake. You saved me about a week worth of research that would have been hopeless aim. I still use diesel + rust just for practice and see if it can handle all these concurrent databases I have. Now I have to go find graph database drivers for rust to get a big picture of where rust is working with. Rust is in a weird place.
Nice, glad the video was helpful even if that came in the form of determining that Diesel wasn't a good fit for your use case! Let us know what you decide to use instead!
@@codetothemoon Yeah I'm reading the Diesel source code over the week and see if I can start contributing or at least trying to integrate it with some other databases similar to [old school perl]. I might know some tricks and resources that most people do not know. I really want to use rust for everything.
Great video!!! I'd love it if you did a video on SeaORM. It's an asynchronous ORM built on top of sqlx. It has support for Postgres, MySQL and SQLite, and also migrations. I tried to use it, but I couldn't understand the documentation :D.
i found the diesel documentation not so easy, this video instead is gold. the normal way diesel works (My program structures -> Db structure) is the opposite that i saw it's used (i already have a db in my company, so diesel have to read the db structures and create structs)
Like always, you make great content! Diesel is not easy to understand you made it quite simple. However, I don't think diesel would be a good great if you have a complex db with a lot of tables. I wish it had that db-first approach, where you create the db first and then generate the Rust codes from it. I'm learning a lot from your videos. So keep it up. Thanks.
Yeah I spent an entire day trying to get that damn diesel CLI working on windows with a new install of Postgres, never got it to work. Basic things in Rust are so much harder, I'm starting to doubt it will actually survive
Diesel is definately on the harder side of the difficulty spectrum as far as SQL crates go - maybe check out sqlx if you want something simpler (disclaimer - I haven't actually tried it myself but I've heard good things)
Had a thought regarding the language. How come we don't have "trait level instance variables"? I often wondered this in C# and Java as well (at interface definition) - you can have properties, but you have to implement OC - and thus are wrappers (overhead). I think it would make sense for methods in same trait to share data on the instance (it's not that they can't now - using struct variables, but the organization is all one bucket) Any thoughts? I know we're not "instantiating a trait" - but there's no reason the trait level data can't be mixed in via the trait (and those variables getting allocated upon struct instantiation). It would be a nice way of knowing immediately what the variable was related to - under the hood, they can "merge" into the struct's definition if needed. The variables would need to be "per trait implementation" in case it was implemented generically several times. This would further enhance the "interface segregation" concept a bit imo, cause not only can you keep them clean by having small interfaces, but also by keeping data related to that interface (trait) tied directly to it. Maybe the top of "impl" block (
LOL I almost spit out my coffee at the Howard Dean scream reference. I've definitely run into a few scenarios where I would have loved to have the ability to put data fields in a trait. Ive been trying to play devils advocate in my head and convince myself why such a feature wouldn't be a good thing, but I haven't been able to come up with anything. It does seem like there is a reason - a quick search revealed this which I haven't actually read yet www.reddit.com/r/rust/comments/ql4gfd/why_cant_you_have_fields_as_traits_in_rust/
Can you make a video about calling APIs from Rust and parse the response as JSON? As silly as it sounds but I've seriously been struggling with that, going from the documentation to vscode back and forth
is there support for databases like teradata or microsoft sql server? I know there is a oracle rust lib, but not sure as to its integration with diesel?
MySQL is always mentioned but never shown. Diesel fails for mysql install on Windows 10 /11 with Visual Studio 2021. I tried to follow up with MySQL 8.00 but I can't get the C++ libraries for MySQL 8.00 to work. Moving forward can we do MySQL demos as well? Can you help?
yikes, that's frustrating. have you tried other Rust SQL libraries like sqlx? I haven't personally tried it yet but it seems to be ultra popular right now
imo it's just on the cusp of being beautiful 😎 many folks don't like using indentation to define scopes, but I personally love it. The thing I can't stomach is the lack of static typing. That's why I think languages like Julia and Lobster are so interesting...
Simply amazing, I got the Gist of diesel with Rust, Do you any plans to make a video using Rust crates which are available for cloud technologies, That gonna be huge help.
thanks Raviraj, glad you found it helpful! I do plan to make more videos on using Rust with various cloud providers. I did make one on using Rust with AWS Lambda, but AWS support for Rust is merely "ok" right now - I plan to explore other providers and evaluate them for Rust "friendliness". Any recommendations on which I should check out?
What about abstracting from a DB implementation? In python for example, you could choose a driver based on what you put in a config (if you installed all the drivers - postgresql, sqlite etc.) and then you can use any database. Could it be implemented in rust? This is a real case when you have onprem deployment for example and you need to support multiple databases
I did not get why the migrations step has to be in SQL. I feel like it could easily do migration with derive macros and rust structs instead of writing raw sql.
I agree it would be super nice to have the SQL completely generated from the Rust model! My best guess as to why the way things are the way they are is that there are low level decisions at the database level that can't necessarily be inferred from the Rust model. Also I think we'd have to maintained "versioned" copies of the Rust model so Diesel can infer a SQL migration from each version (which I guess would be no worse than maintaining raw SQL migrations). All that said, it does seem like it would be technically feasible to have some kind of "opinionated" mode where Diesel writes the raw SQL for you in a way it sees fit.
Hello! Thank you for this excellent tutorial. Unfortunately as of diesel version 2.1.0 this guide has been outdated. Is there a possibility you could remake this tutorial, or correct any minor changes in the repo. Thank you!
I don't necessarily think Rust should be used for everything, but I do feel that it is underutilized in 2022 just because many folks aren't familiar with it. For example, I wouldn't feel comfortable starting a mission critical frontend project in Rust today. But for building nearly any backend service, Rust would be one of the top contenders.
@@codetothemoon Ah. I've so many questions 😅 You don't have to answer but I'm just sharing what I'm curious to know. How did you learn Rust? Did you manage to learn on the fly? How long did it take to not stumble around? What are the not-obvious challenges that are unique to writing Rust, in general? Do you miss ownership and borrowing when using other languages?
Hi! I am very interested in other SQL crates, especially those that are more object oriented, in terms of not being an abstraction over SQL, rather an abstraction over data objects, along the lines of Django orm in Python. And are there any good ORMs that can autogenerate migrations?
Cool, I do plan to cover other SQL crates at some point. Lately it seems like the community is steering more toward options that are perceived to be less complex than Diesel. Re: autogenerating migrations, that would be amazing, I'm not currently aware of any ORMs that do that. Seems like something that would be perfectly feasible though.
(DOUBT) , just like you did for NewVideo , how can I do the same when I have to make it for custom datatypes not strings ? I mean , how can use 'a there , what should be the correct format over custom datatypes which are defined while creating the schema
How do you achieve just typing "rustflix" like normal command in the bash with cargo run ? I would like to create command using rust, but every time I have to type "cargo run " with args, how can I get rid of cargo run and just type my command with args?
Great video and to the point! Thanks for sharing! I don't think having database schema manipulation in the code is a good practice. I would have the schema there so diesel knows how it looks, but I would not apply any migration using it.
thanks, glad you found it valuable! Definitely agree that schema migration is best avoided if possible. Much better to get the perfect schema in the very beginning.
How can I use diesel when releasing the executable? Must user create db manually? Must the user install diesel and run migration commands !? How to release a software without an auto-creation of db an tables?
When i was making this video, I found this to be one of the pain points I foresaw using Diesel in production. At the time this video was made you'd have to run the diesel CLI for the initial DB creation, but you can actually perform subsequent migrations from your code. See the final chapter of the video, "Thoughts on Productionizing"
Hello, great video but could you please not zoom in the terminal as much? I get the idea, but it just makes it way harder/more straining to read than just a slightly bigger font (on top of hiding previous command results).
thanks and that's great feedback! it's definitely a tightrope trying to make things big enough to see but not so big that they cause other things to get pushed out of view...
I'm watching from India i find the audio & video to be out of sync. meaning i hear the audio first and after few seconds the video catches up. would be very helpful if both the audio & video played in sync.
Hey Krishna - thanks for pointing this out. I haven't heard of anyone else having this issue, but I have seen this issue from time to time on CZcams in general. Do you still have this issue if you play the video right now?
"Right now, the idiomatic way to do things is to install the Diesel CLI on your production image, run diesel setup before your application starts, and then call the embedded migrations run function to run any migrations that haven't yet been performed." That seems unwise for several reasons: 1. If your deployment is scaled to more than one instance/pod, you run the risk of race conditions if multiple instances try to do the migration at the same time. Does Diesel actually protect against this? At small scale without much data, maybe the risk is negligible; but if you're at the scale with more instances and enough data where migrations take more than a few seconds, you're playing with fire. 2. "My migrator needs database permission, and my app has database permission, so I'll put the migrator in my app, and it'll have permission!" Migrations require *way* more permission than your app normally needs. `ALTER` / `DROP TABLE` are heavy permissions to entrust your app with. It's like running with sudo 24/7: if you're really careful it might be fine, but it's a lot easier to cause catastrophic damage if you're always running as root - just a matter of time. 3. Bloating production container images with additional dependencies and increased initialization/shutdown complexity: Normally you could get by without a special init process wrapper (e.g. `tini`), but now if you want signals to work correctly realistically you need an init script and/or a separate init container. 4. Decoupling deployment failure from your CI/CD pipeline: Normally, deployment failure logging would be in one place - e.g. GitHub Actions - but now if a migration fails, the error is in your *app's* logging, drowning in a sea of request logs while your other pods continue handling traffic (assuming your init wrapper script didn't wreck the startup probes so that if the pod fails to start, it doesn't steamroll the new, borked app version over the other previously healthy pods). The event that triggered the migration was fundamentally a *deployment* event but now the error reporting becomes a runtime event, which would normally be HTTP requests, etc. - fundamentally an impedance mismatch. 5. "But I want the migration to happen in my app so that it's repeatable!" If your deployment pipeline isn't repeatable then you've got bigger problems, and putting the migration in your app is a bandaid. 6. Startup probe timeouts: Ordinarily you might have a reasonable pod startup timeout of ~5 seconds or something, but now if you have a big enough migration the startup probe fails, so you crank up the threshold for *all* of your pods, even though only one of them should actually even be doing the migration(s). Anyways, does this mean that you can't get away with embedding migrations into your app? No, but I wouldn't call it "idiomatic" but rather "good enough at small scale - YMMV." I don't mean to be a hater - sorry 😅 Just some thoughts. Aside from that this was a really good intro to Diesel - thanks for the info!
I think I got it from a stock sound effects library. It's possible that Terraria used the same sound effect! I spent quite a few hours in that game but didn't notice the similarity lol
@@codetothemoon You have great EQ. ^_^ Diesel looks similar to Django ORM. You give a good teaching for general developers. There are always battle on ORM v.s. SQL. What I learned is layered programming, let each expert exert in their layer. For large scale application systems, I prefer transactional API than coupling code and SQL.
Such a fun way to learn Rust by watching these. Totally sold on Rust at this point. A video about Tauri would be very interesting
Very happy you found it valuable! Tauri is definitely on my radar, will try to make a video on it at some point.
@@codetothemoon 🥳
Really great video! Diesel always seemed very complicated, but your explanations and code were very good. As a suggestion for future video, maybe SQLX can provide a good comparison ground for those who are deciding which one to use. Also, I was wondering if there's an ORM that has async support. That can also make a nice comparison video.
Thank you, I'm glad you found it valuable! and re: SQLX and async ORMs, I'll put these on the potential video roadmap!
Does not have a lot of experience with it but SeaQL/sea-orm looks great. It's async and is based off of sqlx.
@@ejazahmed4609 wasn't aware of this ORM but it looks really good!
diesel-async crate has been released, it has support for mysql and postgres.
Please keep in mind, you can use SQLx and a repository pattern (or something alike) to abstract away your sql. As powerful ORMs are to prototype and for simple CRUD, as big of a pain in the back they can become when you introduce complexity!
Amazing content. I especially appreciate the gotchas that you point out in these videos. Each one probably saves dozens of folks hours of time.
Thanks Zach! I really do hope it saves folks time!
By far the best tutorial i found to tNice tutorials in a short ti
Thanks Franklin!
Thanks for summarizing [diesel] and how it was designed. I was about to use use rust to translate sql files. [diesel] is very complex and time consuming. You have to be a seasoned programming veteran to use this. I wrote script for making a cargo project, just in case I need to use it in the future. But man there is no way a regular programmer is going to get this. I am shocked that diesel only supports postgresql, mysql, and sqlite. I was looking for rust database drivers for mission critical million dollar businesses which usually only use oracle , sybase, db2, postgresql , mssql, and (sometimes) terrcotta+snowflake. You saved me about a week worth of research that would have been hopeless aim. I still use diesel + rust just for practice and see if it can handle all these concurrent databases I have. Now I have to go find graph database drivers for rust to get a big picture of where rust is working with. Rust is in a weird place.
Nice, glad the video was helpful even if that came in the form of determining that Diesel wasn't a good fit for your use case! Let us know what you decide to use instead!
@@codetothemoon Yeah I'm reading the Diesel source code over the week and see if I can start contributing or at least trying to integrate it with some other databases similar to [old school perl]. I might know some tricks and resources that most people do not know. I really want to use rust for everything.
Great video!!! I'd love it if you did a video on SeaORM. It's an asynchronous ORM built on top of sqlx. It has support for Postgres, MySQL and SQLite, and also migrations. I tried to use it, but I couldn't understand the documentation :D.
Thanks Maximiliano! Re: SeaORM, thanks for putting this on my radar!
@@codetothemoon Thank you! I think you'll like it. It's pretty cool.
Truly an awesome channel, keep it up!
thanks for the kind words! will do!
i found the diesel documentation not so easy, this video instead is gold.
the normal way diesel works (My program structures -> Db structure) is the opposite that i saw it's used (i already have a db in my company, so diesel have to read the db structures and create structs)
this is great for my project of making a custom server for a game! i really needed help learning sql and rust structs
nice!! glad you got something out of it!
Glad I found this channel. A gold mine.
Thanks for the kind words, happy you found it as well!
Like always, you make great content! Diesel is not easy to understand you made it quite simple. However, I don't think diesel would be a good great if you have a complex db with a lot of tables. I wish it had that db-first approach, where you create the db first and then generate the Rust codes from it. I'm learning a lot from your videos. So keep it up. Thanks.
Consistently great videos, thank you so much!
thanks and thanks for watching!!
Yeah I spent an entire day trying to get that damn diesel CLI working on windows with a new install of Postgres, never got it to work. Basic things in Rust are so much harder, I'm starting to doubt it will actually survive
Diesel is definately on the harder side of the difficulty spectrum as far as SQL crates go - maybe check out sqlx if you want something simpler (disclaimer - I haven't actually tried it myself but I've heard good things)
Had a thought regarding the language. How come we don't have "trait level instance variables"? I often wondered this in C# and Java as well (at interface definition) - you can have properties, but you have to implement OC - and thus are wrappers (overhead). I think it would make sense for methods in same trait to share data on the instance (it's not that they can't now - using struct variables, but the organization is all one bucket) Any thoughts? I know we're not "instantiating a trait" - but there's no reason the trait level data can't be mixed in via the trait (and those variables getting allocated upon struct instantiation).
It would be a nice way of knowing immediately what the variable was related to - under the hood, they can "merge" into the struct's definition if needed.
The variables would need to be "per trait implementation" in case it was implemented generically several times.
This would further enhance the "interface segregation" concept a bit imo, cause not only can you keep them clean by having small interfaces, but also by keeping data related to that interface (trait) tied directly to it.
Maybe the top of "impl" block (
LOL I almost spit out my coffee at the Howard Dean scream reference.
I've definitely run into a few scenarios where I would have loved to have the ability to put data fields in a trait. Ive been trying to play devils advocate in my head and convince myself why such a feature wouldn't be a good thing, but I haven't been able to come up with anything. It does seem like there is a reason - a quick search revealed this which I haven't actually read yet www.reddit.com/r/rust/comments/ql4gfd/why_cant_you_have_fields_as_traits_in_rust/
Can you make a video about calling APIs from Rust and parse the response as JSON? As silly as it sounds but I've seriously been struggling with that, going from the documentation to vscode back and forth
Check out my OpenAI GPT-3 video, that’s basically what I demonstrate there
Awesome thank you 👌👌
thanks for watching!
Thanks so much for making these videos!
thanks for watching!
is there support for databases like teradata or microsoft sql server? I know there is a oracle rust lib, but not sure as to its integration with diesel?
MySQL is always mentioned but never shown. Diesel fails for mysql install on Windows 10 /11 with Visual Studio 2021. I tried to follow up with MySQL 8.00 but I can't get the C++ libraries for MySQL 8.00 to work. Moving forward can we do MySQL demos as well? Can you help?
yikes, that's frustrating. have you tried other Rust SQL libraries like sqlx? I haven't personally tried it yet but it seems to be ultra popular right now
Beautiful this Lang. Im study and study and study this!
Python is such a beautiful language
imo it's just on the cusp of being beautiful 😎 many folks don't like using indentation to define scopes, but I personally love it. The thing I can't stomach is the lack of static typing. That's why I think languages like Julia and Lobster are so interesting...
Hey, I'm just starting to get into making soft and tNice tutorials 17 minute video helped a LOT MORE than those one hour long tutorials out
🔥
Great video
Thanks Javier!
Simply amazing, I got the Gist of diesel with Rust, Do you any plans to make a video using Rust crates which are available for cloud technologies, That gonna be huge help.
thanks Raviraj, glad you found it helpful! I do plan to make more videos on using Rust with various cloud providers. I did make one on using Rust with AWS Lambda, but AWS support for Rust is merely "ok" right now - I plan to explore other providers and evaluate them for Rust "friendliness". Any recommendations on which I should check out?
What about abstracting from a DB implementation? In python for example, you could choose a driver based on what you put in a config (if you installed all the drivers - postgresql, sqlite etc.) and then you can use any database. Could it be implemented in rust? This is a real case when you have onprem deployment for example and you need to support multiple databases
I did not get why the migrations step has to be in SQL. I feel like it could easily do migration with derive macros and rust structs instead of writing raw sql.
I agree it would be super nice to have the SQL completely generated from the Rust model! My best guess as to why the way things are the way they are is that there are low level decisions at the database level that can't necessarily be inferred from the Rust model. Also I think we'd have to maintained "versioned" copies of the Rust model so Diesel can infer a SQL migration from each version (which I guess would be no worse than maintaining raw SQL migrations). All that said, it does seem like it would be technically feasible to have some kind of "opinionated" mode where Diesel writes the raw SQL for you in a way it sees fit.
Hello!
Thank you for this excellent tutorial. Unfortunately as of diesel version 2.1.0 this guide has been outdated. Is there a possibility you could remake this tutorial, or correct any minor changes in the repo.
Thank you!
Do you know a rust library to implement a GUI?
Edit: would be nice to expand this project with more functionalities and some GUI.
Not accurate to the video but this Rust as a framework approach is intriguing. Do you think Rust should be the basis for everything? Or why not?
I don't necessarily think Rust should be used for everything, but I do feel that it is underutilized in 2022 just because many folks aren't familiar with it. For example, I wouldn't feel comfortable starting a mission critical frontend project in Rust today. But for building nearly any backend service, Rust would be one of the top contenders.
@@codetothemoon That makes sense. How is Rust is to work with in a large codebase, and how is it to read?
@@tobias3581 unfortunately I can't speak to working with it in a large codebase yet, haven't had an opportunity to use it on a larger project
@@codetothemoon Ah. I've so many questions 😅 You don't have to answer but I'm just sharing what I'm curious to know. How did you learn Rust? Did you manage to learn on the fly? How long did it take to not stumble around? What are the not-obvious challenges that are unique to writing Rust, in general? Do you miss ownership and borrowing when using other languages?
Hi! I am very interested in other SQL crates, especially those that are more object oriented, in terms of not being an abstraction over SQL, rather an abstraction over data objects, along the lines of Django orm in Python. And are there any good ORMs that can autogenerate migrations?
Cool, I do plan to cover other SQL crates at some point. Lately it seems like the community is steering more toward options that are perceived to be less complex than Diesel. Re: autogenerating migrations, that would be amazing, I'm not currently aware of any ORMs that do that. Seems like something that would be perfectly feasible though.
Uuu nice clicky keyboard!
Thanks! I loved this keyboard but I've since switched to a quieter one because I got some complaints lol
@@codetothemoon too bad, the clicky sound was actually a nice clicky, not annoying but like there, working in the background.
(DOUBT) , just like you did for NewVideo , how can I do the same when I have to make it for custom datatypes not strings ? I mean , how can use 'a there , what should be the correct format over custom datatypes which are defined while creating the schema
How do you achieve just typing "rustflix" like normal command in the bash with cargo run ? I would like to create command using rust, but every time I have to type "cargo run " with args, how can I get rid of cargo run and just type my command with args?
In case you did not figure it out til now xd : cargo build -release. Then look under /target/release for the binary to run
Next ti, can you install one of those apps that creates a circle around your mouse pointer? Sotis it’s hard for to find where
Good idea, will start doing this from now on!
thank you man
you're welcome, thanks for watching!
Great video and to the point!
Thanks for sharing!
I don't think having database schema manipulation in the code is a good practice.
I would have the schema there so diesel knows how it looks, but I would not apply any migration using it.
thanks, glad you found it valuable! Definitely agree that schema migration is best avoided if possible. Much better to get the perfect schema in the very beginning.
What’s the correct way of doing integration tests with the DB and Postgres? I can’t find any standard test runner
How can I use diesel when releasing the executable? Must user create db manually? Must the user install diesel and run migration commands !? How to release a software without an auto-creation of db an tables?
When i was making this video, I found this to be one of the pain points I foresaw using Diesel in production. At the time this video was made you'd have to run the diesel CLI for the initial DB creation, but you can actually perform subsequent migrations from your code. See the final chapter of the video, "Thoughts on Productionizing"
Coming from a Django world, i would rather write Rust code and let Diesel create Up and Down migrations for me, is that possible?
thank you 😊
you're very welcome, thanks for watching!
Any tips? I’m a newbie learning
The Rust book is fantastic! Anything in particular that you're stuck on?
Were you using m1 or m2 processor for this presentation?
Hello, great video but could you please not zoom in the terminal as much? I get the idea, but it just makes it way harder/more straining to read than just a slightly bigger font (on top of hiding previous command results).
thanks and that's great feedback! it's definitely a tightrope trying to make things big enough to see but not so big that they cause other things to get pushed out of view...
I'm watching from India i find the audio & video to be out of sync. meaning i hear the audio first and after few seconds the video catches up. would be very helpful if both the audio & video played in sync.
Hey Krishna - thanks for pointing this out. I haven't heard of anyone else having this issue, but I have seen this issue from time to time on CZcams in general. Do you still have this issue if you play the video right now?
"Right now, the idiomatic way to do things is to install the Diesel CLI on your production image, run diesel setup before your application starts, and then call the embedded migrations run function to run any migrations that haven't yet been performed."
That seems unwise for several reasons:
1. If your deployment is scaled to more than one instance/pod, you run the risk of race conditions if multiple instances try to do the migration at the same time. Does Diesel actually protect against this? At small scale without much data, maybe the risk is negligible; but if you're at the scale with more instances and enough data where migrations take more than a few seconds, you're playing with fire.
2. "My migrator needs database permission, and my app has database permission, so I'll put the migrator in my app, and it'll have permission!" Migrations require *way* more permission than your app normally needs. `ALTER` / `DROP TABLE` are heavy permissions to entrust your app with. It's like running with sudo 24/7: if you're really careful it might be fine, but it's a lot easier to cause catastrophic damage if you're always running as root - just a matter of time.
3. Bloating production container images with additional dependencies and increased initialization/shutdown complexity: Normally you could get by without a special init process wrapper (e.g. `tini`), but now if you want signals to work correctly realistically you need an init script and/or a separate init container.
4. Decoupling deployment failure from your CI/CD pipeline: Normally, deployment failure logging would be in one place - e.g. GitHub Actions - but now if a migration fails, the error is in your *app's* logging, drowning in a sea of request logs while your other pods continue handling traffic (assuming your init wrapper script didn't wreck the startup probes so that if the pod fails to start, it doesn't steamroll the new, borked app version over the other previously healthy pods). The event that triggered the migration was fundamentally a *deployment* event but now the error reporting becomes a runtime event, which would normally be HTTP requests, etc. - fundamentally an impedance mismatch.
5. "But I want the migration to happen in my app so that it's repeatable!" If your deployment pipeline isn't repeatable then you've got bigger problems, and putting the migration in your app is a bandaid.
6. Startup probe timeouts: Ordinarily you might have a reasonable pod startup timeout of ~5 seconds or something, but now if you have a big enough migration the startup probe fails, so you crank up the threshold for *all* of your pods, even though only one of them should actually even be doing the migration(s).
Anyways, does this mean that you can't get away with embedding migrations into your app? No, but I wouldn't call it "idiomatic" but rather "good enough at small scale - YMMV."
I don't mean to be a hater - sorry 😅 Just some thoughts. Aside from that this was a really good intro to Diesel - thanks for the info!
0:13 Terraria item sell sound?
I think I got it from a stock sound effects library. It's possible that Terraria used the same sound effect! I spent quite a few hours in that game but didn't notice the similarity lol
@@codetothemoon epic
id love a mongodb version!
That would be fun to make - I’ll put it on the idea list!
@@codetothemoon awesome!!
No MSSQL support ?
Something easy in rust
Sa . It's hard when you look at the software
🔥
Nice video!.. I'm trying to create a Generic Repository, but I'm dying. T_T
thanks! what do you mean by Generic Repository?
How to handle transactions.
28 years Oracle DBA still think plain SQL is better. :)
hah! Plain old SQL is hard to beat. Talk about standing the test of time!
@@codetothemoon You have great EQ. ^_^ Diesel looks similar to Django ORM. You give a good teaching for general developers.
There are always battle on ORM v.s. SQL. What I learned is layered programming, let each expert exert in their layer. For large scale application systems, I prefer transactional API than coupling code and SQL.
tNice tutorials tutorial was very satisfying
thanks glad you found it valuable!
Why is this so complicated? All I want to do is query data from a database
Diesel probably isn't what you're looking for then. Take a look at sqlx! I haven't tried it myself but I've heard great things.
@@codetothemoon Thank you!
Elon musk!!?
sick of it!! !!!! anybody got any tips to help?? close on throwing my laptop out the window! got the Full package on soft feel its a waste of
🔥
rust
🦀🦀🦀!
Whenever I search for "Rust + DB" it always results in Diesel. Could you perhaps lend some love towards "SeaQL/sea-orm"? :D