Zend Framework

Inconsistent backtick usage

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Trivial Trivial
  • Resolution: Won't Fix
  • Affects Version/s: 1.7.2
  • Fix Version/s: 1.9.3
  • Component/s: Zend_Db_Adapter_Mysqli
  • Labels:
    None

Description

When creating a query, and then checking the actual query using __toString(), it seems backtick usage is inconsistent. Given the following code:

$select = $db->select()
                 ->from(array('iv'  => 'indicator_version'))
                 ->columns(array('type' => new Zend_Db_Expr("'".self::TYPE_VERSION_DATA."'")))
                 ->join(array('ivc' => 'country_indicator_version'), 'iv.id = ivc.indicator_version_id', array('value' => 'ivc.value', 'show_footnote' => 'ivc.show_footnote', 'footnote_desc' => 'ivc.footnote_desc'))
                 ->join(array('c'   => 'country'), 'ivc.country_id = c.id', array('country' => 'c.name', 'country_id' => 'c.id' ,'fips_code'=>'c.fips_code'))
                 ->join(array('i'   => 'indicator'), 'iv.indicator_id = i.id', array('sort' => 'i.sort'))
                 ->where('iv.id = ?', (int) $version_id)
                 ->where('ivc.value IS NOT NULL')
                 ->order('ivc.value desc');

I currently get the following query:

SELECT 
	`iv`.*, 
	'versiondata' AS `type`, 
	`ivc`.`value`, 
	`ivc`.`show_footnote`, 
	`ivc`.`footnote_desc`, 
	`c`.`name` AS `country`, 
	`c`.`id` AS `country_id`, 
	`c`.`fips_code`, 
	`i`.`sort` 
FROM 
	`indicator_version` AS `iv` 
INNER JOIN 
	`country_indicator_version` AS `ivc` 
ON 
	iv.id = ivc.indicator_version_id 
INNER JOIN 
	`country` AS `c` 
ON 
	ivc.country_id = c.id 
INNER JOIN 
	`indicator` AS `i` 
ON 
	iv.indicator_id = i.id 
WHERE 
	(iv.id = 2) 
AND 
	(ivc.value IS NOT NULL) 
ORDER BY 
	`ivc`.`value` desc

As you can notice WHERE clauses and the ON clauses for joins do not have backticks. At first, I thought this to be related to the fact that those strings are literally added in our code, but then I noticed that the value of the ORDER clause does have backticks (even though we didn't add backticks in our code). So it seems in some situations, backticks are added, but in others they aren't. This seems inconsistent and may result in problems when using specific field names.

Activity

Hide
Satoru Yoshida added a comment -

This issue also happens on 1.8.0 ?

Show
Satoru Yoshida added a comment - This issue also happens on 1.8.0 ?
Hide
Stefan Koopmanschap added a comment -

I have not yet tried this with 1.8.0 but since there was no other ticket describing this issue I believed it would most probably not be fixed yet.

Show
Stefan Koopmanschap added a comment - I have not yet tried this with 1.8.0 but since there was no other ticket describing this issue I believed it would most probably not be fixed yet.
Hide
Ralph Schindler added a comment -

I dont see this as much of an issue.

The unquoted parts of that expression are passed in by the user. They are used raw. The Zend_Db_Select object simply cannot know whats in the where part of the string, and automagically quote it accordingly. If the developer wants special quotes on the parts they are supplying, they can use $db->quoteIdentifier().

I am inclined to close as not an issue

-ralph

Show
Ralph Schindler added a comment - I dont see this as much of an issue. The unquoted parts of that expression are passed in by the user. They are used raw. The Zend_Db_Select object simply cannot know whats in the where part of the string, and automagically quote it accordingly. If the developer wants special quotes on the parts they are supplying, they can use $db->quoteIdentifier(). I am inclined to close as not an issue -ralph
Hide
Josh Butts added a comment -

Seems like the backticking could be updated based on the params passed to ->join()

Show
Josh Butts added a comment - Seems like the backticking could be updated based on the params passed to ->join()
Hide
Ralph Schindler added a comment -

I am classifying this as an improvement as I see no direct failure of queries due to missing backticks, and since very few people would be using mysql reserved words as identifiers.
Marked as "trival", prob 1h of work, can be introduced in "next mini release"

Show
Ralph Schindler added a comment - I am classifying this as an improvement as I see no direct failure of queries due to missing backticks, and since very few people would be using mysql reserved words as identifiers. Marked as "trival", prob 1h of work, can be introduced in "next mini release"
Hide
Ralph Schindler added a comment -

Assigning to Luke for closure.

Show
Ralph Schindler added a comment - Assigning to Luke for closure.
Hide
Luke Barton added a comment -

I am resolving as Won't Fix as the issue is minor and there is no attractive solution.

Ralph and I concluded that whilst it is inconsistent to `backtick` raw sql snippets passed to the order() method, the available options are unappealing.

Removing `backticking` of raw SQL order() strings is not an option we'd like to take; since it would create an issue for those relying upon the existing functionality to quote reserved keywords in table/column names, and contradicts Zend_Db's ideal of quoting where possible.

Adding automatic `backticking` to all raw SQL statements (for consistency) is unrealistic due to the work required compared with the benefit it would bring.

Show
Luke Barton added a comment - I am resolving as Won't Fix as the issue is minor and there is no attractive solution. Ralph and I concluded that whilst it is inconsistent to `backtick` raw sql snippets passed to the order() method, the available options are unappealing. Removing `backticking` of raw SQL order() strings is not an option we'd like to take; since it would create an issue for those relying upon the existing functionality to quote reserved keywords in table/column names, and contradicts Zend_Db's ideal of quoting where possible. Adding automatic `backticking` to all raw SQL statements (for consistency) is unrealistic due to the work required compared with the benefit it would bring.

People

Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
1h
Original Estimate - 1 hour
Remaining:
1h
Remaining Estimate - 1 hour
Logged:
Not Specified
Time Spent - Not Specified