That’s normally an option for your manifest file (e.g., a Gemfile or package.json), but most production applications also (sensibly) use a lockfile. Updating the versions in that lockfile is what Dependabot is great for.
I agree! I find this especially useful when I have to set things like a UserId associated with an entity or with more complex entities where some data comes from injected services. I know you can create a service that handles creating the entity as an abstraction, but that gets repetitive and adds complexity in large projects. I might actually add this my article :)!
I know, I just couldn't find a cross-db solution since I can't seem to find any standardized error codes in the exception. Do you know of a better way of doing this?
I do not know of a good Cross DB solution. It may be more elegant to check specific exception types for the DBMSs that you do use. For example, MySQL would be:
I would just delete that part if it can't be solved. Smaller issues with code are, that you create new string just to compare it (ToLower makes new instance), when you can achieve this just by using proper comparer such as
I done a fair bit of performance problem fixing now in my career and I have never seen a .ToLower be the cause of any client's performance problems. Or really any string manipulation opinion like stringbuilder vs += and all that nonsense.
If you want to get really picky you should be converting to uppercase and ToUpperInvariant in particular:
From C# via the CLR:
Important If you want to change the case of a string's characters before performing an ordinal comparison, you should use String’s ToUpperInvariant or ToLowerInvariant method. When normalizing strings, it is highly recommended that you use ToUpperInvariant instead of ToLowerInvariant because Microsoft has optimized the code for performing uppercase comparisons. In fact, the FCL internally normalizes strings to uppercase prior to performing case insensitive comparisons. We use ToUpperInvariant and ToLowerInvariant methods because the String class does not offer ToUpperOrdinal and ToLowerOrdinal methods. We do not use the ToUpper and ToLower methods because these are culture sensitive.
I agree with you. But I also think you're sacrificing clarity over brevity yourself by not expanding "pre-optimization" into "premature optimization" ;)
I myself really dislike that piece of code (searching in exception strings isn't secure for many reasons, for example someone could use this to reverse-engineer information about my database). But the only alternative that comes to mind is to check if an entity exists before attempting to create it - which I don't like because it leads to repetitive code in large projects (and I might forget to write checks). Any other ideas?
Yes, that is the usual way of doing it. However, the point of this post was to showcase some ways of reducing duplicate code in large projects. Doing it normally (by checking if the entity already exists) can get repetitive if you have many controllers/entities. If you know of a better way of doing this, I'd be happy to update my article :)
Well the server was going to return an error anyways, instead of checking if the entity exists then trying to create it, you just go ahead and try to create it. This way if the entity doesn't exist then you've saved a trip to the database. Otherwise you return the same error. And given the server is a black box, how would you "interrupt execution"?
Cierge is stateless so it doesn't matter if you have 100 login tabs open, it'll always work - and once the code is entered it is automatically invalidated.
Cierge is an OpenID Connect sever (which is based on OAuth 2), so your website would interact with it just as it would with non-passwordless solutions.
