Color collision

[r-richmond]

Right now it looks like the colors for each table are using a hash of the name. (Note: I haven't taken the time to look through the code to verify)

While this is clever it appears very close collisions can occur more often than one might suspect.

As an example i'm unable to visually tell the difference between d_player_account & d_region

Can you provide an option to incrementally assign colors rather than based on a hash.

i.e. table 1 gets a pre-determined color, table 2 gets a pre-determined color, etc...

[DavidLGoldberg]

I've used this for a year with fairly large SQL files (good sql and some obnoxious crap sql). Most of the time I don't run into collisions. And the tool is largely, additive. Of course it can trip you up sometimes. One thing you can always do is bind the toggle action, so that in some situations you can turn it off... not great but a stop gap.

Hashing, yes that's how it works. The md5 hashing colors is cool, so that all users everywhere can see the same colors for the same strings, and start committing them to memory.

Often we're using the same table in multiple files, so having them rotate different colors across files I think would quickly become a shit show unfortunately...

Your idea is cool because per user, the tables will all have the same colors. We could make it bundles of colors per app / domain.. But I think it's a lot of work and I don't think I'd ever take the time to set them...just to avoid a collision or 2.

I have been revisiting this whole issue myself recently, and I'm currently interested in finding some other way to represent a difference. For instance breaks/patterns in the line, or on the background for the word/letter with colliding colors.

I'm working through a few ideas:

1. how / look and feel
   • backgrounds
   • breaks in line
   • squiggly lines
   • different font's
   • 2 colors in line (leaning away from this......but i'm very curious to see what that looks like for some reason...although I know that's probably wayyy too busy...almost some kind of IQ test at that point, but maybe with 2 colors the brain handles it? Not sure would be fun to test.)
     • a. (what's the least number of the above needed to be introduced such that the odds of a new multidimensional collision are too low to care about...)
2. Should we always show this new dimension, so that all strings effectively have 2 outputs of every hash/string or just when there's a "collision" (colors within some range)? See: http://apps.usd.edu/coglab/WebersLaw.html https://en.wikipedia.org/wiki/Weber%E2%80%93Fechner_law
3. how to make that visually noticeable for 1 letter aliases (90% of aliases I see out there, although I avoid that practice these days personally in my SQL)
4. Make this optional so that I can quickly turn out a beta?
   • a. make it default?
   • b. go live with multiple implementations?

[DavidLGoldberg]

Hah, can't believe I didn't have an issue open to improve this stuff.... Oops. I'm going to rename it to something a bit more generic.

[r-richmond]

Hmm you have a good point about the cons & complexity required for using static predefined lists.

Can I suggest an easier alternative?

Can you add a seed option to the package? so that when you hash the table name to get the color it uses hash(get_seed() + table_name)

The default value would be an empty string so that the colors don't change.

& provide 3 new commands 1) Set Seed value - changes the seed to a user input 2) Reset Seed value which changes it back to an empty string (aka the default) 3) Set random Seed value - changes the seed to a random value. For example: the current clock time yyy-mm-dd hh:mm:ss.

The idea here being that if a user experiences a collision they can change the seed value until they find something without a collision.

As far as finding another way to represent a difference it is going to be very tough to beat colors. Something that comes to mind is shapes but that doesn't fit nicely under the text and I would be opposed to it being in the same horizontal space as my text. (I don't think it would be useful in the gutter either)