Pattern acceleration support #65
Conversation
…atches, refactor ConditionWalkers and improve tests
|
All new classes now have only final values and public methods always return the same value after instantiation (weakly immutable). I included some refactoring of old classes but I think the project would require a larger refactoring to be more object-oriented. Made project issues regarding refactoring |
| import static com.teragrep.pth_06.jooq.generated.bloomdb.Bloomdb.BLOOMDB; | ||
| import static org.jooq.impl.SQLDataType.*; | ||
|
|
||
| /** |
There was a problem hiding this comment.
Please write detailed javadoc about the logic behind the table structure and the query pattern. It is not very obvious to decode the schema and the query from the code.
There was a problem hiding this comment.
39adb13 Added better javadoc for BloomFilterTempTable in an effort to clear up the logic.
| .leftJoin(BLOOMDB.FILTERTYPE) | ||
| .on(BLOOMDB.FILTERTYPE.ID.eq((Field<ULong>) t.field("filter_type_id"))) | ||
| .where(finalPatternCondition) | ||
| .limit(1) |
There was a problem hiding this comment.
why limit 1 is present? this limits the search token to make only one of the possible bloomfilters as a candidate instead of having all as possible candidates?
There was a problem hiding this comment.
please comment the code to indicate the purpose
There was a problem hiding this comment.
All tables in bloomdb are checked in turn by the filterTables() function, limit is just for the single table to avoid loading all of it's rows to memory, since it makes the filter if it has even just 1 matching row.
I will add the comment to clear the purpose
eemhu
dismissed
their stale review
Not knowledgeable enough about this functionality to give explicit approval
| .leftJoin(BLOOMDB.FILTERTYPE) | ||
| .on(BLOOMDB.FILTERTYPE.ID.eq((Field<ULong>) t.field("filter_type_id"))) | ||
| .where(finalPatternCondition) | ||
| .limit(1) |
There was a problem hiding this comment.
please comment the code to indicate the purpose
| private final ConditionConfig config; | ||
| private final Set<Table<?>> tableSet; | ||
| private final long bloomTermId; | ||
| private final List<Condition> conditionCache; |
| private final Table<Record> tableName; | ||
| private final long bloomTermId; | ||
| private final Set<Token> tokenSet; | ||
| private final List<Condition> cache; |
There was a problem hiding this comment.
to limit the SQL operations if the Condition is already generated. Should I refactor them to work without caches?
| } | ||
|
|
||
| @Test | ||
| void fromStringIntendTest() throws Exception { |
There was a problem hiding this comment.
changing existing test will not do, please revert the changes.
|
Refactoring of old code split into another PR |
|
Moving PR to another branch |
Pattern acceleration