[
https://issues.jboss.org/browse/TEIIDDES-2802?page=com.atlassian.jira.plu...
]
Paul Richardson updated TEIIDDES-2802:
--------------------------------------
Description:
An sql query, such as the following, parses but drops the cache hint
{code}
/* leading comment */ /*+ cache(ttl:180000) */ SELECT col1 FROM tbl
{code}
However, the same sql without the 'leading comment' retains the cache hint.
The reason is that Designer uses the same parser handling syntax as the Teiid parser. Both
use a regular expression for handling the cache hint, ie.
{code}
"/\\*\\+?\\s*cache(\\(\\s*(pref_mem)?\\s*(ttl:\\d{1,19})?\\s*(updatable)?\\s*(scope:(session|vdb|user))?\\s*(min:\\d{1,19})?[^\\)]*\\))?[^\\*]*\\*\\/.*";
{code}
The dot-star (.*) at the end allows for the rest of the sql after the cache hint but there
is no allowance for any comments prior to the cache hint. In order to handle this an extra
pragma needs to prefix the regular expression above:
{code}
"(?:/\\*[^\\+].+?\\*/(?:\\s+)?)?"
{code}
* (...)? => an optional group so no comment is handled
* ?: => the group is non-capturing so ignored by the matcher group count
* [^\\+] => checks for a + following the comment opener. Cache hints are expected to
use this so this distinguishes a normal comment from a cache hint
* .+? => makes the comment contents non-greedy so the first comment closer is found
rather than the last
* (?:\\s+)? => non-capturing optional group that checks for any whitespace between the
end of the comment and the cache hint
Example patch for Designer parser added.
This cannot be rectified in Designer until it is rectified in Teiid. Even then, older
versions of Teiid will never support this.
was:
An sql query, such as the following, parses but drops the cache hint
{code}
/* leading comment */ /*+ cache(ttl:180000) */ SELECT col1 FROM tbl
{code}
However, the same sql without the 'leading comment' retains the cache hint.
The reason is that Designer uses the same parser handling syntax as the Teiid parser. Both
use a regular expression for handling the cache hint, ie.
{code}
"/\\*\\+?\\s*cache(\\(\\s*(pref_mem)?\\s*(ttl:\\d{1,19})?\\s*(updatable)?\\s*(scope:(session|vdb|user))?\\s*(min:\\d{1,19})?[^\\)]*\\))?[^\\*]*\\*\\/.*";
{code}
The dot-star (.*) at the end allows for the rest of the sql after the cache hint but there
is no allowance for any comments prior to the cache hint. In order to handle this an extra
pragma needs to prefix the regular expression above:
{code}
"(?:/\\*[^\\+].+?\\*/(?:\\s+)?)?"
{code}
* (...)? => an optional group so no comment is handled
* ?: => the group is non-capturing so ignored by the matcher group count
* [^\\+] => checks for a + following the comment opener. Cache hints are expected to
use this so this distinguishes a normal comment from a cache hint
* .+? => makes the comment contents non-greedy so the first comment closer is found
rather than the last
* (?:\\s+)? => non-capturing optional group that checks for any whitespace between the
end of the comment and the cache hint
Example patch for Designer parser added.
Address co-existence of SQL comment and cache hint
--------------------------------------------------
Key: TEIIDDES-2802
URL:
https://issues.jboss.org/browse/TEIIDDES-2802
Project: Teiid Designer
Issue Type: Bug
Components: Teiid Integration
Affects Versions: 9.2, 10.0
Reporter: Paul Richardson
Attachments: 0001-Patch-to-address-failures-in-comments-and-cache-hint.patch
An sql query, such as the following, parses but drops the cache hint
{code}
/* leading comment */ /*+ cache(ttl:180000) */ SELECT col1 FROM tbl
{code}
However, the same sql without the 'leading comment' retains the cache hint.
The reason is that Designer uses the same parser handling syntax as the Teiid parser.
Both use a regular expression for handling the cache hint, ie.
{code}
"/\\*\\+?\\s*cache(\\(\\s*(pref_mem)?\\s*(ttl:\\d{1,19})?\\s*(updatable)?\\s*(scope:(session|vdb|user))?\\s*(min:\\d{1,19})?[^\\)]*\\))?[^\\*]*\\*\\/.*";
{code}
The dot-star (.*) at the end allows for the rest of the sql after the cache hint but
there is no allowance for any comments prior to the cache hint. In order to handle this an
extra pragma needs to prefix the regular expression above:
{code}
"(?:/\\*[^\\+].+?\\*/(?:\\s+)?)?"
{code}
* (...)? => an optional group so no comment is handled
* ?: => the group is non-capturing so ignored by the matcher group count
* [^\\+] => checks for a + following the comment opener. Cache hints are expected to
use this so this distinguishes a normal comment from a cache hint
* .+? => makes the comment contents non-greedy so the first comment closer is found
rather than the last
* (?:\\s+)? => non-capturing optional group that checks for any whitespace between the
end of the comment and the cache hint
Example patch for Designer parser added.
This cannot be rectified in Designer until it is rectified in Teiid. Even then, older
versions of Teiid will never support this.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)