Make node/edge labels & property names case-insensitive

[drkameleon]

Having a person, Person, PERSON types of nodes and all of these meaning something different doesn't make a lot of sense.

The same could be said for property names.

---

Related: https://github.com/arturo-lang/arturo/commit/6c51de602d3fa63fd995d9724430ae853f9e6ca0

[drkameleon]

Ready to merge 🚀

[dumblob]

Hm, I'd actually prefer having everything case-sensitive. The world is moving towards having things in IT case sensitive and adding some rules nobody remembers about case sensitivity doesn't sound really good to me.

How about making it easy for users to lowercase labels everywhere where it matters? Maybe some syntax support instead of using a function?

[drkameleon]

Hm, I'd actually prefer having everything case-sensitive. The world is moving towards having things in IT case sensitive and adding some rules nobody remembers about case sensitivity doesn't sound really good to me.

How about making it easy for users to lowercase labels everywhere where it matters? Maybe some syntax support instead of using a function?

I'm totally pro case-sensitivity, in general. I just thought it wouldn't make much in a graph db case, as I highlight above.

However, I must admit this design choice in particular has made me question myself since I made it.

Let me research a bit about it...

[dumblob]

Actually I always thought of making a "meta structure" describing labels. At least some hierarchy (i.e. tree structure) of labels would be useful. But if I wanted to create such meta structure, I'll definitely want it to be case sensitive.

But maybe I'm misunderstanding what your motivation really is. Maybe you truly have some good reasons for this decision. I'm just out of ideas and have no clue what case insensitivity would help with (except for "negative" side effects like confusion to users, impossibility of having consistency - gets really bad once one starts to automate things and needs to precisely describe this "meta behavior" of the engine the automation is to interact with, etc.).

[drkameleon]

Actually I always thought of making a "meta structure" describing labels. At least some hierarchy (i.e. tree structure) of labels would be useful. But if I wanted to create such meta structure, I'll definitely want it to be case sensitive.

But maybe I'm misunderstanding what your motivation really is. Maybe you truly have some good reasons for this decision. I'm just out of ideas and have no clue what case insensitivity would help with [...]

Your comment was definitely food-for-thought.

So... I spent the weekend brainstorming and reading about it (especially how other graph databases handle it).

First of all, let me re-iterate that I have always been a total fan of case-sensitivity (and not the opposite). That being said, even Arturo itself (while in the general REBOL group, which promotes case-insensitivity) is totally case-sensitive.

Now, given that Grafito basically makes use of Arturo's syntax, the normal way to do things would be to follow its example. Why did I come up with idea of case-insensitive node-types and fields? Pretty much for what I mentioned in the initial message: to... avoid confusion (and for the number of times I've seen a question along the lines of "How do I query WHERE person.name='something' OR person.Name='something' at the same time?").

So... I went on to see how others already do it.

If we have a look at the existing RDBMSs, the situation is a total mess. Most are case-insensitive, some are selectively case-insensitive, Oracle SQL is case-sensitive, and even with SQLite I've had some hard time figuring out what is going on occasionally. As for Graph databases, the absolute norm is: case-sensitivity everywhere.

After all that and given that this decision of mine has already produced me more than one headache, I think I'm totally going to revert this change and go back to the former, already tried-and-proven model: case-sensitivity. Grafito, given that it is like Arturo++ actually, only for graph databases, is not any SQL-type of language. It's a full-blown general-purpose one. And as such, there are numerous ways we can do things, or force case-insensitivity for that matter, in case we want to. (we already have an option for db-wide "case-insensitivity" as a matter of fact, and this could even be specified - though not yet - on a per-query basis).

Regarding this:

except for "negative" side effects like confusion to users, impossibility of having consistency - gets really bad once one starts to automate things and needs to precisely describe this "meta behavior" of the engine the automation is to interact with, etc

what can I say. I couldn't agree more...

So, alea jacta est. 😉

[dumblob]

Ok, very well. Thanks!

and this could even be specified - though not yet - on a per-query basis

Yes, this should cover the occasional verbose cases (this reminds me of me using grep -Ei sometimes - i.e. also per-query :wink:).