contributors entries are case sensitive about haxelib HOT 23 OPEN

Ok, I'll make it consistently case insensitive then. It would be quite confusing to have a Simn and a simn on haxelib, where both are distinct people.
Also, we'd have to make URLs case sensitive, such as http://lib.haxe.org/u/Simn

Anybody in favor of case sensitivity?

from haxelib.

The database doesn't allow registering simn if Simn exists, so the check has to be case insensitive everywhere.

from haxelib.

Case insensitive ftw!

Leave the worries about case sensitive URLs to the API team.

On Sun, Jun 9, 2013 at 7:29 PM, Simon Krajewski [email protected]:

The database doesn't allow registering simn if Simn exists, so the check
has to be case insensitive everywhere.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/59#issuecomment-19164631
.

from haxelib.

tumbleweed

from haxelib.

The database doesn't allow registering simn if Simn exists

Is this really true? I started to look at this issue, and my local sqlite-based repo allowed to register both nadako and Nadako, what am I missing?

from haxelib.

Oh, it's probably different for MySQL. Anyway that raises the question about how to do case insensitive queries with SPOD. I came up with:

User.manager.unsafeObjects("SELECT * FROM User WHERE lower(name) = " + sys.db.Manager.quoteAny(name.toLowerCase()), true)

But this doesn't look good. Maybe we could add a .toLowerCase() support in RecordMacros that generates lower(field) cc @ncannasse

from haxelib.

RTFM :) http://dev.mysql.com/doc/refman/5.7/en/case-sensitivity.html
MySQL uses case insensitive matching by default, which I think is good for user names (every website you login is case insensitive I suppose)

from haxelib.

Haxelib server doesn't seem to check for existing user names and the name field is not marked as UNIQUE. So it's possible to register several users by the same name, which is just wrong. Could we use name field as a primary key and get rid of the id?

from haxelib.

This strikes me as a big deal actually. I wonder how many people "successfully" registered duplicating user names.

from haxelib.

@jasononeil could you look into that urgently ?

from haxelib.

Note that I added the check in d679e23

from haxelib.

We need to check the production database for users with duplicate names (case-insensitive) and remove all but one, and fix references to those user in Project and Developer tables.

from haxelib.

Totally unrelated question of course, but does our server make backups of the haxelib database?

from haxelib.

Might as well double that question with the database for the haxe.org blog.

from haxelib.

Might as well triple that question with the content/files of haxelib.

from haxelib.

library files should be on a CDN really (see #33)

from haxelib.

As @ncannasse told me when I picked up the server last month, no, there is currently no backup mechanism in place.
I think we should hire a sys admin...

from haxelib.

I think we should hire a sys admin...

Indeed! A sysadmin probably could help with restoring data for #253 from http server logs :)

from haxelib.

That's not too hard to parse ;)

from haxelib.

If this is not a joke it would be awesome.

from haxelib.

Thinking more about this, with rewriting I don't think the logs have enough information for that.

from haxelib.

Maybe we should just use AWS or something.

from haxelib.

Yes, server management is an area we're lacking, because there's not that much things that needs to be done, so we need someone to help occasionally. It's not in that much bad shape, but there things that should be done. Any volunteer ? :)

from haxelib.