Feature #1586
Feature #1585: add conversion and runtime support for word indexes
add quick and dirty support for word indexes using LIKE operator
100%
Related issues
History
#1 Updated by Eric Faulhaber over 11 years ago
- Start date deleted (
10/15/2012)
#2 Updated by Greg Shah over 11 years ago
- Target version set to Milestone 7
#3 Updated by Eric Faulhaber over 11 years ago
- Assignee set to Ovidiu Maxiniuc
- Target version changed from Milestone 7 to Milestone 4
This issue isn't really about word indexes per se, but it is a quick and dirty precursor to true word index support, which we eventually will implement using something like Lucene or Hibernate Search.
This is about supporting the 4GL CONTAINS operator using an SQL LIKE operator. We already do something similar for the 4GL BEGINS operator. Please look at that code as a guide. Note that we don't expect this to be efficient for very large text records, which is why we have the follow up issue #1587.
#4 Updated by Ovidiu Maxiniuc about 11 years ago
- Status changed from New to WIP
I learned that this operator is a little strange, only works on whole words (btw, the field on which it is applied must be word-indexed) but on the other hand, is flexible enough to allow rather complicated search using parenthesis, "and" and "or" operators which connect more words prefixes. I am thinking of transforming CONTAINS string parameter into some regexp. I am not sure if sql LIKE is powerful enough, but I will do some dirty work there.
#5 Updated by Eric Faulhaber about 11 years ago
For the current project, the use of CONTAINS is very consistent. The AST generally looks like:
contains [KW_CONTAINS] myField [FIELD_CHAR] myVar [VAR_CHAR]
which corresponds to:
... myField CONTAINS myVar ...
What this means is that myVar will drop out as a query substitution parameter in all cases, and it will need to be processed/converted to an SQL LIKE phrase at runtime, not conversion time. We do something similar for the BEGINS and MATCHES operators, using character.convertToSQLBegins(myVar) and character.convertToSQLLike(myVar), respectively. Let's add a runtime stub for character.convertToSQLContains(character) and wrap the right operand (e.g., myVar) of KW_CONTAINS with a call to this new method.
This is a temporary solution until we have full word index support, so I don't want to put any significant effort into this solution that will not translate to the permanent solution. For now, since we don't have to parse any of the CONTAINS-specific syntax at conversion time, don't spend any time implementing character.convertToSQLContains(character). We will need to implement this for Milestone 7, however.
#6 Updated by Ovidiu Maxiniuc about 11 years ago
- File om_upd20130212c.zip added
- File om_upd20130212d.zip added
Implemented temporary solution.
Some more details were added to the javadoc of character.convertToSQLContains() method.
#7 Updated by Eric Faulhaber about 11 years ago
- % Done changed from 0 to 50
- Status changed from WIP to Test
We are regression testing the update as is, which contains conversion support and some of the runtime implementation. Note that we also will need a server-side implementation of the contains function (i.e., PL/Java).
#8 Updated by Eric Faulhaber about 11 years ago
- File om_upd20130214b.zip added
Sorry, I misspoke (mistyped?) in my last update. I made some minor changes to the 20130212c drop to merge with newer versions of some of the files and to fix a javadoc error. The update being tested is attached.
#9 Updated by Eric Faulhaber about 11 years ago
- % Done changed from 50 to 100
- Status changed from Test to Closed
Update was regression tested and checked into bzr revision 10173.
#10 Updated by Greg Shah over 7 years ago
- Target version changed from Milestone 4 to Conversion Support for Server Features