-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Escape column name #168
base: develop
Are you sure you want to change the base?
Escape column name #168
Conversation
The field there now requires quotation marks around itself. This is likely because in the SELECT bit of the query the fields are also provided with quotation marks.
On linux, databases tend to be case-sensitive with their tests. This test failed in part because the column is `userId` not `userid`
In the 3 ways a Foreign Key Constraint may be generated the field does not get escaped. This causes issues in the tests.
This appears to now be mandatorily necessary
…l fields For some reason the tests of tcount fail, because the model in there has another model in it, which generates an FK field that then looks like this: ""favToy"" Which causes SQL errors.
…tation marks. Why that is I have no idea.
@@ -56,7 +56,7 @@ suite "Table creation": | |||
|
|||
check dbConn.getAllRows(qry, "FurnitureTable") == @[ | |||
@[?"id", ?"bigint"], | |||
@[?"legcount", ?dftDbInt] | |||
@[?"legCount", ?dftDbInt] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An example for sudden case-sensitivity, though that is when comparing column names and not during actual queries, not sure how much that matters.
@@ -80,7 +80,7 @@ suite "Table creation": | |||
] | |||
|
|||
check dbConn.getAllRows(qry, "Pet") == @[ | |||
@[?"favtoy", ?"bigint"], | |||
@[?"favToy", ?"bigint"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An example for sudden case-sensitivity, though that is when comparing column names and not during actual queries, not sure how much that matters.
@@ -219,7 +220,7 @@ suite "Row CRUD": | |||
|
|||
let | |||
personRow = get dbConn.getRow(sql"""SELECT name, pet, id FROM "Person" WHERE id = $1""", person.id) | |||
petRow = get dbConn.getRow(sql"""SELECT species, favToy, id FROM "Pet" WHERE id = $1""", pet.id) | |||
petRow = get dbConn.getRow(sql"""SELECT species, "favToy", id FROM "Pet" WHERE id = $1""", pet.id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An example for suddenly required quotation marks, necessary only on the FK field "favToy", not on the others.
Same for Line 71
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if you put the rest in quotations for consistency? Does it break the test?
This is so weird 🤔 Possibly, this has to do with mixing cases. If the column name uses mixed case, it must be quoted. But that's just a wild guess.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing the line to this: sql"""SELECT "species", "favToy", "id" FROM "Pet" WHERE id = $1"""
Still works perfectly fine.
An observation I made though, is that this:
sql"""SELECT "sPecies", "favToy", "id" FROM "Pet" WHERE id = $1"""
Will cause the test to fail while this:
sql"""SELECT sPecies, "favToy", "id" FROM "Pet" WHERE id = $1"""
works perfectly fine.
I'm getting the impression that not only are suddenly the quotation marks sometimes mandatory, they cause the column names to suddenly be case-sensitive.
@@ -70,6 +72,6 @@ suite "``fk`` pragma": | |||
for inpCustomer in inpCustomers.mitems: | |||
dbConn.insert inpCustomer | |||
|
|||
dbConn.select(outCustomers, """"userid" = $1""", userA.id) | |||
dbConn.select(outCustomers, """"userId" = $1""", userA.id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An example for sudden case-sensitivity, though that is when comparing column names and not during actual queries, not sure how much that matters.
@@ -33,7 +32,7 @@ suite "Import dbTypes from norm/private/postgres/dbtypes": | |||
|
|||
test "dbValue[DateTime] is imported": | |||
let users = @[newUser()].dup: | |||
dbConn.select("""lastLogin <= $1""", ?now()) | |||
dbConn.select(""""lastLogin" <= $1""", ?now()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An example for suddenly required quotation marks, this time not on an FK field as lastLogin is of type DateTime. Not sure what that is about.
src/norm/postgres.nim
Outdated
else: | ||
fkGroups.add "FOREIGN KEY ($#) REFERENCES $#(id)" % [fld, (obj.dot(fld).getCustomPragmaVal(fk)).table] | ||
fkGroups.add """FOREIGN KEY ("$#") REFERENCES $#(id)""" % [fld, (obj.dot(fld).getCustomPragmaVal(fk)).table] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to add quotation marks here because otherwise the FK constraints wouldn't have any.
Please note that I ONLY added the quotation marks in these two lines.
There is a third line dealing with FK constraints, line 107 further up, where I DID NOT add quotation marks around the field, because when that line gets called by tests the field suddenly already has quotationmarks (possibly because it calls the col proc where the others don't).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when that line gets called by tests the field suddenly already has quotationmarks (possibly because it calls the col proc where the others don't).
Oof, that's dangerous behavior. col proc should be called always.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just tried it, replacing fld
on there with obj.col(fld)
does work.
I'm not sure if the code that generates is correct, as stated I haven't read through this code in any intensity in order to understand what's going on, but it does pass the tests.
…eneration I do not know whether obj.col(fld) actually is correct code, but it *does* run through all tests.
I'm perfectly fine with leaving this PR in the air as it is, as I'm not sure myself what to do with this. Is this grounds for not accepting the PR? |
This is a copy of #159 but with fixes applied by me to get the tests running.
@cmd410 @moigagoo
The main reason I didn't commit them onto the branch of @cmd410 is because I actually don't know how ^^'
For the general description, refer to #159 and a related userstory #165
GENERAL REMARK:
I noticed some worrying behaviour which I think might cause this PR to be one that break backwards compatibility.
A fair amount of the tests in postgres did not run because they either:
I did not think any deeper into that or investigate why this was suddenly the case or if it doesn't matter for the library user, it was mostly an observation I made while fixing the testing errors.
To me this looks like new behaviour and a breaking change.
It might of course also just be that I ran the tests under linux and this might be fine under windows, but it is something to take a look at either way.