Priority: Enhancement
Current State: Closed
Released In:
Target Release:
The encoding of chars like newline-linefeed are encoded to fit them into a %META:FIELD. However when searching for a value in formfields using regular expressions these encodings are not what you'd like to deal with. For instance, a keyword search like
Comments=~'\bOracle\b'
won't find topics that have "Oracle" in the first column/second line as this is encoded as
%0d%0aOracle
. The extra
%0a
before the string prevents it to be found although it should.
The obvious solution would be to decode any formfield before caching it as the cache does not require the data to be encoded.
I can't think of a case where matching the specific entity-encoded strings is desirable. Crawford, can you?
--
MichaelDaum - 24 Feb 2009
No, but I also can't think of a case where a regular expression search of formfield data is a good idea. Most DBs only support the LIKE operator, and supporting regex searches would require iteration over the entire DB. I would far rather deprecate the use of regex searches outside of the topic text completely. The encoding is highly specific to the inefficiency of the current store implementation.
--
CrawfordCurrie - 24 Feb 2009
However you motivate it - either by regexing formfields or otherwise - I can't see a reason to cache formfields in encoded format.
Do you agree?
--
MichaelDaum - 24 Feb 2009
Yes. The encoding is a mechanism used by the textfile-based store, and should not reach the cache.
--
CrawfordCurrie - 26 Feb 2009
I changed to using readTopic rather than doing a native read, this problem should no longer apply.
--
CrawfordCurrie - 07 Apr 2009