I was watching a course about JDBC and when the Instructor was speaking about ? (Question Mark) in Prepared Statement, he said:
Before I execute the Query, I have to fill in the placeholders or parameters.
he was talking about a query like this:
SELECT * FROM Employee where salary > ?
Now, my main question is:
what is difference between placeholder and parameter?
and isn't he wrong? can ? be either placeholder or parameter?
Edit:
I consider these two definition also:
argument is the value/variable/reference being passed in, parameter is the receiving variable
There is no difference, these are just two terms used for the same things. Which is probably why that phrase was used: to introduce both terms and indicate they can be used interchangeably. There is even a third variant where both are combined in a single term: parameter placeholder.
As I see it, the ? is a placeholder for a value, but at the same time a parameter for the query.
Related
SELECT * FROM table1 WHERE year_month BETWEEN '2021-08' AND '2022-01';
update table2 set note_description = 'test #8:57am', patient_id = '5840', note_updated_by = '10000019', note_update_date = '2022-07-13 09:45:49' where note_id = '639'
now my backend queries can be attacked by sql injection so i want to avoid the sql injection
in the above queries I want to separate the parameters from queries and replace it with special characters so that I can avoid sql injection is there any package or anything to do it.
If you have received the SQL statement with the parameters already concatenated in, then this is the wrong place to fix your issue - there’s no way to safely parse the statement and separate out the parameters from the query.
You should find the place in the code where the parameters are concatenated into the Statement and leveraging Prepared Statements/Parameterized Queries to safely pass/bind the parameters.
If that’s not possible (for example because the code is structured to only pass along the statement) a less desirable alternative is to encode/enquote the parameters before concatenating them in, while ensuring they are all quoted in the statement. How you do that part will depend on the database / language being used.
I've seen one product that does this: pt-query-digest. It's a free tool that parses the MySQL query log, and produces reports of aggregate time spent running each query. To do this, it must establish a query "fingerprint" which allows it to group queries that are the same except for constant values. Like SELECT * FROM mytable WHERE id = 123 has the same fingerprint as SELECT * FROM mytable WHERE id = 456.
This means it must parse the queries and replace each constant value, like a numeric or string literal, with a placeholder ?. In cases of IN() predicates, it replaces the list of values with ?+. Also it reduces whitespace and removes comments.
It's a non-trivial amount of code, about 100 lines of Perl: https://github.com/percona/percona-toolkit/blob/3.x/lib/QueryRewriter.pm#L139-L248
In spite of this, the function is preceded by a comment that the developers acknowledge it is not perfect, and may miss some cases. Implementing a recursive-descent parser using regular expressions is not efficient or correct.
But this is probably not what you want to do anyway. You shouldn't be starting from a query with constant values and making them into a parameterized query. You should design parameterized queries yourself, as needed.
Not every constant value in an SQL query necessarily must be parameterized. Only the ones that aren't fixed values. That is, if you need to combine a variable from your client code into the SQL query string, and you can't guarantee that the variable is safe, then use a parameter. If a query has a constant value that is fixed (not interpolated from a variable), then it can remain in the query. If a query has a value that comes from a variable, but that variable is known to be safe, and never can be tainted by untrusted input, then it can remain in the query.
It's more reliable and economical for you to make these judgments. You know the code and the context much better than any automated system can.
I have the following transformation in Pentaho PDI (note the question mark in the SQL statement):
The transformation is called from a job. What I need is to get the value from the user when the job is run and pass it to the transformation so the question mark is replaced.
My problem is that there are parameters, arguments and variables, and I don't know which one to use. How to make this work?
What karan means is that your sql should look like delete from REFERENCE_DATA where rtepdate = ${you_name_it}, and check the box Variable substitution. The you_name_it parameter must be declared in the transformation option (click anywhere in the spoon panel, Option/Parameters), with or without a default value.
When running the transformation, you are prompted with a panel where you can set the value of the parameters, including you_name_it.
Parameters pass from job to transformation transparently, so you can declare you_name_it as a parameter of the job. Then when the user run the job, it will be prompted to give values to a list of parameters, including you_name_it.
An other way to achieve the same result, is to use arguments. The question marks will be replaced by the fields specified in the Parameters list box, in the same order. Of course the field you use must be defined in a previous step. In your case, a Get variable step, which reads the variable defined in the calling job, and put them in a row.
Note that, there is a ready made Delete step to delete records from a database. Specify the table name (which can be a parameter: just Crtl+Space in the box), the table column and the condition. The condition will come from a previous step defined in a Get parameter like in the argument method.
You can use variables or arguments. If you are using variables then use
${variable1}
syntax in your query and if you want to use arguments then you have to use? In your query and mention the names of those arguments in "Field names to be used as arguments" section. Both will work. Let me know if you need further clarifications.
Question:
Is there a way to use names instead of question marks for paramaterized queries? If so, can anyone suggest some material that explains how to do this/the syntax?
A bit more detail:
For example, if I have something like:
INSERT INTO inventory VALUES(?)
Is it possible to have something like this instead that does the exact same thing as the question mark:
INSERT INTO inventory VALUES("prices")
I tried checking to see if it would work myself before posting the question, but it didn't work. So, I thought I'd ask if it was possible.
I feel like if you have a really long query with, let's say 20 parameters, you don't want to have to count question marks to make sure you have enough parameters whenever you change something. Also, I think it might make the code a bit more readable (especially if you have a lot of parameters to keep track of).
I'm rather new to sql, so I am not sure if it makes much of a difference (for this question) if I add that I'm using postgresql.
Note:
There is a similar question here, but it didn't have an answer that was helpful
I suggest to encapsulate the big query in a function, where you can use parameter names.
One example (out of many):
PostgreSQL parameterized Order By / Limit in table function
You can even set default values and call the function with named parameters, etc.:
Functions with variable number of input parameters
Recently, I have come to analyze a procedure in which they have used below scenario.
I want to know what is the usefulness of this ?
A procedure (cwrkid, date)
select statement
WHERE CWRK.cwrkid = NVL(in_cwrk_id,CWRK.cwrkid)
and in_cwrk_id is passed null. SO obviously, CWRK.cwrkid = CWRK.cwrkid
will always match... What the point in using variables and passing null, and ultimately satisfying a truth condition.
Am I mising something or am I thinking a lot.. :P
This is useful if you want to make the procedure reusable in future development. For now the only usecase is to select all records, but if you ever need to get only one record with a given ID you can also use this procedure.
The point is that the caller can decide whether a filter on cwrkid should be applied. One call to that function may pass NULL for that parameter, to not apply any filter. Another call to that function may pass some value for that parameter, if that caller does want to apply a filter.
I say that no filter gets applied, but I am assuming that the column is not nullable. If the column is nullable, then nulls will be filtered out, regardless of what gets passed in as the parameter value.
Normally, code like this is used to have a default behaviour in case the parameter is NULL. In this case, the WHERE-condition normally restricts to records with the given cwrkid. However, if cwrkid is null, there is no restriction.
Without the NVL, the WHERE-condition would not match at all.
Why this was done in this case is impossible to know without knowing more about the procedure and its purpose.
I see this:
Project.update_all("cost = cost * 3",
"lower(technology) LIKE '%microsoft%'")
as an example of update_all method in Active Record when I'm following The Rails 3 Way, very simple phrase, huh? But I just can't figure out what do parentheses mean in lower(technology) here.
So, Could you tell me some possible answers? Because I don't know if there are some different situations we can use parentheses like this.
thanks.
They call the SQL LOWER function to lowercase the string.
LOWER technology
would be a syntax error, because LOWER is a function, not a keyword.