PostgreSQL, camelCase and tests

[Sebastian Machuca]

So, I'm a big fan of PostgreSQL. It's actually the DB that I like the most.

I was disappointed when looking at the test, I found that there is almost no tests against PostgreSQL. So, I decided to fork the project and try to give support to PostgreSQL and I found on of the first obstacles and I would like to have your opinion and explanation about this matter.

The requirement for test, stipulates some conditions and one condition is not that easy to follow in PostgreSQL/frameworks.

A valid answer for the /db test is similar to :

{"id":3217,"randomNumber":2149}

The problem?

The camelCase in the second item, randomNumber.

For MySQL and Mongo is native to have this, but as for PostgreSQL is an anti-pattern. It is supported, but not recommended. The suggest is always lowercase for both, name of tables and columns.

Everyone could argue that the solution is trivial, and usually it is trivial. But that increase the amount of logic to process if you want to do a benchmark test.

So, what are we testing? Is not a simple access to database, or multiple access to this one? In real life, we usually don't have this sort of problems, and if the situation exists we usually wouldn't have big problem to fix it. But the problem in concrete I am having is that I have to add more logic for handle this and that is just noice in the test.

My propose would be allow a response with everything in lowercase or underscore in the case camelCase is not "native" for the database. 

This should be valid as well:

{"id":3217,"random_number":2149}

What do you think?

If so, we can include PostgreSQL in the tests in more equal conditions.

And, I know if you query with "nameOfColumn" works, but the problem is that not all frameworks follow that and just send the lowercase name.

On the other hand, I know I can define everything in lowercase in the db, and rename the result, but again, is extra logic that degrade the performance test adding noise and not measuring what the test is really designed for (at least what I understand that the test was designed for)

[kainsavage44]

As for camel casing, we are (may have already) changed the rules here to allow different capitalization. There is no good reason to disallow "randomnumber" but allow "randomNumber" from a data stance.

However, we are maintaining our rules for formatting the output to not have additional/fewer characters, as that would change the size of the response body and would have an effect on the benchmark. You can imagine, if you are returning "random_number" and another test is returning "randomNumber", your tests will be returning 1 extra character per request, which can add up rather quickly. Additionally, we have some tests failing validation because they are returning bodies like: { world: { "id": "1234", "randomNumber": "9876" } }. Again, you see that while they are technically fulfilling the requirements, they are responding with way too many unnecessary characters.

TL;DR - Case-sensitivity will not be enforced in round 10, but validation to ensure that no extra/fewer characters are in the response will.

-Mike Smith
Systems Architect
TechEmpower