Simplify your development process - download my free Clean Architecture template: bit.ly/3Andaly
@coding-in
23 күн бұрын
Thanks Milan, how to address if we need call validation without its command? I have downloaded the template, is there a docs guidelines?
@iteospace
6 күн бұрын
Hey, Milan how about distributed databases like Cassandra, ScyllaDb, YugabyteDb based on LSM Tree
@hybridloo
22 күн бұрын
Milan, I love how you tackle core production use cases and scenarios that we all face every day, and how you solve them easily. Keep up the awesome work!
@MilanJovanovicTech
22 күн бұрын
Thanks a lot! :)
@nouchance
23 күн бұрын
Dear Milan I like your coding style:)
@MilanJovanovicTech
23 күн бұрын
Thanks, much appreciated! :)
@cazorla82
23 күн бұрын
How to use distributed lock in Sql Server instead of Postgre?
@MilanJovanovicTech
23 күн бұрын
There are: - sp_getapplock (learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-getapplock-transact-sql) - sp_releaseapplock (learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-releaseapplock-transact-sql)
@jaimelannister141
23 күн бұрын
I liked your style of presentation but I think you didn't really address the title of your video. It's about distributed locking and you assumed we had to stick to Postgres and after that resorted to a uniqueness index. Well, not every case of distributed locking happens when dealing with a relational database. I was looking for an in-depth explanation of something like the Redlock algorithm and an attempt to implement it.
@MilanJovanovicTech
23 күн бұрын
I'll cover Redlock in a future (well-named) video!
@jaimelannister141
23 күн бұрын
@@MilanJovanovicTech Thank you. I'm definitely looking forward to it
@ALOKSHARMAMD
22 күн бұрын
nice, i didnt knew we could use when statements like these in c#. i have been using unique indexes similar to your solution but i threw whole exception without specifics , thanks.
@MilanJovanovicTech
22 күн бұрын
Yeah, this is one of these useful C# features that not many people know of
@kattamanchiarjun
16 күн бұрын
Isn't the problem you stated can be sloved by eTag concept? Is distributed lock the right approach to solve this concurrency or race condition issue?
@MilanJovanovicTech
16 күн бұрын
How would ETag solve this?
@dhruvmathur5315
22 күн бұрын
Thanks for the videos amazing content
@MilanJovanovicTech
22 күн бұрын
Most welcome!
@JonathanGabrielSilva
23 күн бұрын
Hey guys... someone can tell witch is de milan theme for visual studio? i love it, but didnt figure out...
@MilanJovanovicTech
23 күн бұрын
@@JonathanGabrielSilva it's ReShaper, plus its syntax highlighting :)
@hailuong9295
23 күн бұрын
he use VS2022 default dark theme, but he also use Resharper so code color is little bit different than the stock one in VS2022
@JonathanGabrielSilva
23 күн бұрын
thank you! now my code is almost beautful like milan's code... xP
@mdmoniruzzaman2922
22 күн бұрын
what do you think about optimistic lock for same last product ordering by two or more users in a distributed system?
@MilanJovanovicTech
22 күн бұрын
If we already have an entity than optimistic concurrency should be fine
@luizadolfo1
22 күн бұрын
Considering your previous videos on using soft delete, this approach can generate errors when a user is deleted and a new user is registered with the same email.
@MilanJovanovicTech
22 күн бұрын
But we're not using soft deletes here?
@hafizabdullah7488
19 күн бұрын
Try a combination of email and the soft delete flag when creating the index
@bentosalvador336
23 күн бұрын
Thanks for your content. I really like it. I have quetion regarding UseCase concept. I dont know if you are basing on clean arch (uncle Bob) cocept. If so, dont you think you are leaking tech/infra details into your usecase, with this implementation?
@MilanJovanovicTech
23 күн бұрын
A use case is a pretty generic concept. One use case = one piece of functionality.
@bentosalvador336
21 күн бұрын
@@MilanJovanovicTech yeah, thats is the reason I specified if you was baseing on Uncle Bob concept of usecase. From Uncle Bob words: "We do not expect this layer [usecases] to be affected by changes to externalities such as the [database], the UI, or any of the common frameworks. This layer is isolated from such concerns."
@aminmemar416
17 күн бұрын
so we can remove first email check if right?
@MilanJovanovicTech
17 күн бұрын
Yes
@user-xm7sh3vw8o
23 күн бұрын
Is this one better than Redis lock? Then what should I do if there is no unique field for inventory increase or decrease?
@MilanJovanovicTech
23 күн бұрын
I wouldn't call it better, but it's definitely a simpler option if you're already using Postgres. No additional infrastructure needed. If there's no unique field, like in your case, use a lock.
@user-xm7sh3vw8o
23 күн бұрын
@@MilanJovanovicTech 👍
@akashrokade12
19 күн бұрын
In line 28 why have you used add method… when you are trying to update
@MilanJovanovicTech
19 күн бұрын
Am I not creating a new user?
@alexlo5655
23 күн бұрын
Hi Milan, thank you for the video. Can you present the same but with the Redis lock?
@MilanJovanovicTech
23 күн бұрын
Yes!
@ahmedameen2
22 күн бұрын
Great video, can you tell me how to handle a use case where new item should have unique auto increment counter?
@poneciak57
22 күн бұрын
Database should handle that depending on your database u can check for example SERIAL for postgres
@MilanJovanovicTech
22 күн бұрын
Autoincrementing PK?
@ahmedameen2
21 күн бұрын
@@MilanJovanovicTech it's auto increment field not primary+ this will be applied per tenant not global counter. So, there could be itemRefNum=5 with tenant x and itemRefNum=5 with tanant y
@MilanJovanovicTech
21 күн бұрын
@@ahmedameen2 Is it important for it to be a counter? Each tenant has to start with 1, then 2, etc.?
@ahmedameen2
21 күн бұрын
Yes unfortunately it's a business need @@MilanJovanovicTech
@Maxim.Shiryaev
23 күн бұрын
And the Users.Exists() check is redundant. By the way, ef core doesn't support unique constraints that makes it impossible to use deferred constraints when needed. Only unique indexes that can not be deferred.
@MilanJovanovicTech
23 күн бұрын
I left it for fail fast principle, but yeah, it's redundant if we handle the concurrency exception
@Meryovi
23 күн бұрын
... I was about to say that a unique index was probably a better option in this particular scenario, then you went ahead and did just that. Haha.
@MilanJovanovicTech
23 күн бұрын
There we go 😁
@KingOfBlades27
23 күн бұрын
That is indeed picky but true for sure 😅
@MilanJovanovicTech
23 күн бұрын
Which approach would you use?
@androidsavior
21 күн бұрын
Summary: use db unique index
@MilanJovanovicTech
21 күн бұрын
TL;DW
@androidsavior
21 күн бұрын
@@MilanJovanovicTech 😅😅 I enjoyed it, i'm gonna try the redlock. Thank you
@davearkley7014
23 күн бұрын
I know this is picky, but please consider calling an EmailAddress just that, not Email. An Email has a sender, recipient, subject. body etc.
@MilanJovanovicTech
23 күн бұрын
The Email on the User entity?
@joga_bonito_aro
23 күн бұрын
I hate nitpick commits.
@cheeseburger1884
23 күн бұрын
never thought about it that way :o
@teothe
23 күн бұрын
Sorry but isn't the purpose of a lock to ensure that whatever you have beneath it will succeed and not throw exceptions and/or have an invalid state in your data? You check if the email exists but then you depend on the infrustructure to enforce it? this is not simple it's, at best, inefficient, if not prone to ddos attacks use locks and if the app is in many instances just put the lock somewhere accessable for all
@MilanJovanovicTech
23 күн бұрын
Also factor in the likelihood of a race condition here. It's pretty low. Locks are an overkill for this. Use a unique constraint.
@teothe
23 күн бұрын
@@MilanJovanovicTech Depending on database exceptions is also an overkill
@herve952
23 күн бұрын
Why would you add this extra complexity for a scenario that is really not likely to happen. I'd say near as likely as losing the connection to the db, which will throw also. The goal is not to prevent the error from happening, rather it is to enforce uniqueness. And what better place than the actual place the live in to do it.
@joga_bonito_aro
23 күн бұрын
@@teothe I don't think this is meant for the gigazillion user base application. Rather for a really low user count that is easy to comprehend.
@teothe
23 күн бұрын
@herve952 @joga_bonito_aro @MilanJovanovicTech just to clarify, i am not objecting to having a unique constrain on the db but it is one thing to have something to safeguard your persistant state and another to use this in the app the email uniqueness comes as a business requirement, and as such you must treat it and as early as possible if for the business is a very serious matter, you do a proper lock or a distributed one, if it is something that they don't really care, you just go with the db constrain but in any case you should never let exceptions define the behaviour of your app, an exception raised from classA and an exception raised from classB should always result in the exact same behaviour
Пікірлер: 66