-
Sub-task
-
Resolution: Done
-
Major
-
None
-
None
-
None
-
None
-
NEW
-
NEW
Not just limited for V&V, could be used by any editor. With a few changes.
The problems
Speed
The problem with the old V&V is that it freezes the browser even with 500 line rules. The fix we currently have for this is running the V&V checks in small chunks, letting the browser breath every now and then.
In the future this will not work. One DTable view might show several DTables, this means we get to the 500 line gap faster.
Row based inspections
Also, with the current implementation is row based. Meaning that we inspect individual rows and adding rows quite fast. When removing or adding columns actually resets all the checks and indexing, making all the validation work start from 0. V&V should also work if the rule/rules it is validating are in a table/two tables/single DRL or in any other rule format.
Listening to changes. If a cell changes. We reset the checks that include that line.
Search with iteration
For loops inside for loops inside for loops... This is how V&V does it's searchin now.
Range checks
Any range check is a check on a column. It basically hits every issue above.
The Fix
The fix is to make better indexing.
- One that is not based on row or columns, but on rules, patterns, fields and constraints.
- Getting all the constraints on a row is as fast as getting all the constraints on a column.
- It is possible to make a search, save the search and listen changes on the search. This way if a single Cell changes, we only update the validation checks that care about it. If a column is removed, again we only update the searches that care.