Django raw SQL query trouble with format characters and string interpolation - mysql

In my Django app, I need to generate a MySQL query like this:
SELECT * FROM player WHERE (myapp_player.sport_id = 4 AND (myapp_player.last_name LIKE 'smi%'))
UNION
SELECT * FROM player WHERE (myapp_player.sport_id = 4 AND (myapp_player.first_name LIKE 'smi%'));
I can't use Q objects to OR together the __istartswith filters because the query generated by the Django ORM does not use UNION and it runs at least 40 times slower than the UNION query above. For my application, this performance is unacceptable.
So I'm trying stuff like this:
Player.objects.raw("SELECT * FROM myapp_player WHERE (sport_id = %%s AND (last_name LIKE '%%s%')) UNION SELECT * FROM sports_player WHERE (sport_id = %%s AND (first_name LIKE '%%s%'))", (sport.id, qword, sport.id, qword))
I apologize for the long one-liner, but I wanted to avoid using a triple-quoted string while trying to debug this type of issue.
When I execute or repr this queryset object, I get exceptions like this:
*** ValueError: unsupported format character ''' (0x27) at index 133
That's a single-quote in single quotes, not a triple-quote. If I get rid of the single-quotes around the LIKE clauses, then I get a similar exception about the close-paren ) character that follows the LIKE clause.
Apparently Django and MySQL disagree on the correct syntax for this query, but is there a syntax that will work for both?
Finally, I'm not sure that my %%s syntax for string interpolation is correct, either. The Django docs suggest that I should be able to use the regular %s syntax in the arguments for raw(), but several online resources suggest using %%s or ? as the placeholder for string interpolation in raw SQL.
My sincere thanks for just a little bit of clarity on this issue!

I got it to work like this:
qword = word + '%'
Player.objects.raw("SELECT * FROM myapp_player WHERE (sport_id = %s AND (last_name LIKE %s)) UNION SELECT * FROM myapp_player WHERE (sport_id = %s AND (first_name LIKE %s))", (sport.id, qword, sport.id, qword))
Besides the fact that %s seems to be the correct way to parameterize the raw query, the key here was to add the % wildcard to the LIKE clause before calling raw() and to exclude the single quotes from around the LIKE clause. Even though there are no quotes around the LIKE clause, quotes appear in the query ultimately sent to the MySQL sever.

Related

Select * from Select

Its very weird situation I know, nut I have got myself into it somehow. I have to connect to some other system service by passing some parameters in url.
In their service they are creating some query using parameter I pass.
For my case I have to pass 'Select' as a parameter name which is actually some class name on their side. So they end up in creating query as Select * from select
and some condition.
On execution I am getting error response as:
'There was a syntax error in a SQL query or filter expression at line
1, position 186. Saw \"Select\" but expected
'..SQL: \"SELECT col1, col2 FROM Select AS D where
some condition.
Can somebody help me on this.
Since Select is reserved word, you have to escape it by enclosing in backticks characters in order for MySQL to process your query:
select * from `select`
Its recommended not to use MySQL reserved keywords.. but if its necessary there is a solution..
Use this, it will work for you :
select * from yourdatabasename.select

Using PDO and LIKE not working, why?

I'm using PDO to connect to MySQL. Everything is working fine, except this doesn't work.
Does anyone knows why? And how should i do it?
SELECT * FROM flagIt WHERE :flagids LIKE CONCAT('%', flagIt.flagIt_id, '%')
:flagids is equivalent to a string like "ID1 ID2 ID3".
EDIT (just to compare)
SELECT * FROM flagIt WHERE 'ID1 ID2 ID3' LIKE CONCAT('%', flagIt.flagIt_id, '%)
If i use like this, it works fine, so...why it does not work with :flagids?
I hope you understand my problem.
Thank you very much.
EDIT
I tried:
"SELECT * FROM flagIt WHERE flagIt.flagIt_id IN(:flagids)"
and as Hobo Sapiens suggested
"SELECT * FROM flagIt WHERE FIND_IN_SET(flagIt.flagIt_id, :flagids)"
and nothing works!!!!!!!!!
This is the query you're submitting to PDO::prepare():
SELECT * FROM flagIt WHERE :flagids LIKE CONCAT('%', flagIt.flagIt_id, '%')
The process of preparing a statement doesn't just involve evaluating the contents of the placeholders, substituting them in a string and executing the resulting query.
A prepare asks the server to evaluate the query and prepare an execution plan that includes the table and indexes it will use. For that it needs to know which columns of which tables it must work with, which is why one cannot use a placeholder where you would need an identifier.
The problem with your query is that the server has no way to know at the time it prepares the statement whether the placeholder represents a string literal or a column identifier. Without that information, the preparation cannot be done, and your prepare will fail.
If you have some flexibility over the value you're using in :flagids you could use find_in_set():
SELECT * FROM flagIt WHERE find_in_set(flagIt_id, :flagids)
where a variable containing, for example, 'ID1,ID2,ID3' is bound to :flagids.
This will be fine for small lists, but will be slow for a large list.
MySQL reference for find_in_set()

nested "select " query in mysql

hi i am executing nested "select" query in mysql .
the query is
SELECT `btitle` FROM `backlog` WHERE `bid` in (SELECT `abacklog_id` FROM `asprint` WHERE `aid`=184 )
I am not getting expected answer by the above query. If I execute:
SELECT abacklog_id FROM asprint WHERE aid=184
separately
I will get abacklog_id as 42,43,44,45;
So if again I execute:
SELECT `btitle` FROM `backlog` WHERE `bid` in(42,43,44,45)
I will get btitle as scrum1 scrum2 scrum3 msoffice
But if I combine those queries I will get only scrum1 remaining 3 atitle will not get.
You Can Try As Like Following...
SELECT `age_backlog`.`ab_title` FROM `age_backlog` LEFT JOIN `age_sprint` ON `age_backlog`.`ab_id` = `age_sprint`.`as_backlog_id` WHERE `age_sprint`.`as_id` = 184
By using this query you will get result with loop . You will be able to get all result with same by place with comma separated by using IMPLODE function ..
May it will be helpful for you... If you get any error , Please inform me...
What you did is to store comma separated values in age_sprint.as_backlog_id, right?
Your query actually becomes
SELECT `ab_title` FROM `age_backlog` WHERE `ab_id` IN ('42,43,44,45')
Note the ' in the IN() function. You don't get separate numbers, you get one string.
Now, when you do
SELECT CAST('42,43,44,45' AS SIGNED)
which basically is the implicit cast MySQL does, the result is 42. That's why you just get scrum1 as result.
You can search for dozens of answers to this problem here on SO.
You should never ever store comma separated values in a database. It violates the first normal form. In most cases databases are in third normal form or BCNF or even higher. Lower normal forms are just used in some special cases to get the most performance, usually for reporting issues. Not for actually working with data. You want 1 row for every as_backlog_id.
Again, your primary goal should be to get a better database design, not to write some crazy functions to get each comma separated number out of the field.

Strange syntax error in MySQL

Why does this give me an MySQL syntax error:
<cfset arguments.where = "platformUrlId='#params.platformUrlId#'">
SELECT *
FROM whatever
WHERE #arguments.where#
Order By #arguments.order#
But this works perfectly well?
<cfset arguments.where = "0=0">
SELECT *
FROM whatever
WHERE #arguments.where#
Order By #arguments.order#
It's not my param because I dumped the param next to a twin that I typed out, and they match... passing the string directly works, but setting the string in an argument then using the argument breaks it
EDIT: The error output is showing platformUrlId=''playstation3'' Coldufsion is adding '' around the argument name. How come?
In order to prevent problems when your variable contians someting like "Dexy's Midnight Runniers", CF implicitly escapes single quotes in CFQuery. You can prevent this by using preserveSingleQuotes().
However, what you are doing is definitely not a recommended practice. If you need to write this as a function, I'd do something more along the lines of passing in an array of key/value pairs, and using cfQueryParam to prevent any SQL injection.
You could probably better make use of the cfqueryparam tag like this:
<cfquery>
SELECT *
FROM tbl
WHERE #arguments.colname# = <cfqueryparam value="#arguments.platformUrlId#">
ORDER BY #arguments.order#
</cfquery>

Combine 'like' and 'in' in a SqlServer Reporting Services query?

The following doesn't work, but something like this is what I'm looking for.
select *
from Products
where Description like (#SearchedDescription + %)
SSRS uses the # operator in-front of a parameter to simulate an 'in', and I'm not finding a way to match up a string to a list of strings.
There are a few options on how to use a LIKE operator with a parameter.
OPTION 1
If you add the % to the parameter value, then you can customize how the LIKE filter will be processed. For instance, your query could be:
SELECT name
FROM master.dbo.sysobjects
WHERE name LIKE #ReportParameter1
For the data set to use the LIKE statement properly, then you could use a parameter value like sysa%. When I tested a sample report in SSRS 2008 using this code, I returned the following four tables:
sysallocunits
sysaudacts
sysasymkeys
sysaltfiles
OPTION 2
Another way to do this that doesn't require the user to add any '%' symbol is to generate a variable that has the code and exceute the variable.
DECLARE #DynamicSQL NVARCHAR(MAX)
SET #DynamicSQL =
'SELECT name, id, xtype
FROM dbo.sysobjects
WHERE name LIKE ''' + #ReportParameter1 + '%''
'
EXEC (#DynamicSQL)
This will give you finer controller over how the LIKE statement will be used. If you don't want users to inject any additional operators, then you can always add code to strip out non alpha-numeric characters before merging it into the final query.
OPTION 3
You can create a stored procedure that controls this functionality. I generally prefer to use stored procedures as data sources for SSRS and never allow dynamically generated SQL, but that's just a preference of mine. This helps with discoverability when performing dependency analysis checks and also allows you to ensure optimal query performance.
OPTION 4
Create a .NET code assembly that helps dynamically generate the SQL code. I think this is overkill and a poor choice at best, but it could work conceivably.
Have you tried to do:
select * from Products where Description like (#SearchedDescription + '%')
(Putting single quotes around the % sign?)
Dano, which version of SSRS are you using? If it's RS2000, the multi-parameter list is
not officially supported, but there is a workaround....
put like this:
select *
from tsStudent
where studentName like #SName+'%'
I know this is super old, but this came up in my search to solve the same problem, and I wound up using a solution not described here. I'm adding a new potential solution to help whomever else might follow.
As written, this solution only works in SQL Server 2016 and later, but can be adapted for older versions by writing a custom string_split UDF, and by using a subquery instead of a CTE.
First, map your #SearchedDescription into your Dataset as a single string using JOIN:
=JOIN(#SearchedDedscription, ",")
Then use STRING_SPLIT to map your "A,B,C,D" kind of string into a tabular structure.
;with
SearchTerms as (
select distinct
Value
from
string_split(#SearchedDescription, ',')
)
select distinct
*
from
Products
inner join SearchTerms on
Products.Description like SearchTerms.Value + '%'
If someone adds the same search term multiple times, this would duplicate rows in the result set. Similarly, a single product could match multiple search terms. I've added distinct to both the SearchTerms CTE and the main query to try to suppress this inappropriate row duplication.
If your query is more complex (including results from other joins) then this could become an increasingly big problem. Just be aware of it, it's the main drawback of this method.