Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Case sensitivity problems in ProGet for Linux
-
Hello,
I'm trying to get rid of the last Windows Server I have, and it's serving some private NuGet feeds using ProGet for my project. I was able to install it successfully on Digital Ocean's server using docker-compose with Nginx in front of it and migrated all the data using CSV files between MS SQL and Postgres.
But then realized I can't use it, because Postgres is not case insensitive like MS SQL, and I can't make it case insensitive by a "global switch".
I have a lot of external users that use those private feeds in their continuous integration environments. There is a high probability that they are using other case for logins and package ids than in the database, like "hangfire.pro" instead of "Hangfire.Pro". This is not a problem when using ProGet for Windows, and it's a more user-friendly approach, since they don't need to guess the proper casing.
I've googled a bit to learn how to make Postgresql's queries case insensitive, and learnt there are two options: use the "citext" data type, or change all queries to use the "LOWER" function. I've tried to change the data type to "citext", and try to login using the different casing, but this does not work at all.
So looks like the only option is to fix all the queries, and I can't perform this on my side. Have you faced with this problem before?
Product: ProGet
Version: 4.7.9
-
Hi there! Any news regarding this topic?
-
We've investigated this bit... and tried converting usernames to citext, but now we get all sorts of other problems. Using LOWER on all the queries will also be an issue from an indexing standpoint.
So, unfortunately that means this has gone from a simple fix to quite the long term project, whcih we're not prepared to take on at the moment... especially with SQL SErver for Linux coming closer and closer each month.
-
Hi Alana,
Thank you for the update. I was quite surprised too when realised we can't use case insensitive collation in Postgres. But what if we have 2 columns, one contains data as is, and one contains normalised data, e.g. Login and LoginNormalized. The first one is indexed, the last one is used in queries. But I understand this leads to different schemas in SQL Server and Postgres.
I completely agree we can bet on SQL Server, but I don't know its licensing options yet. Posgres is working well from my point of view, except this detail. Since a lot of web applications use Postgres and I haven't heard about case sensitive logins yet, I believe that solution exists.
Thank you for all of your hard work on this awesome project!