MultiClassification
Requirements
- unlimited number of classifications for one document (task)
- unlimited number of assigned aspect values in one aspect
Solution
Separate Classifications records are used for every classification which is set. No empty records used, a document has as many Classifications records as many classifications are set.
Issues
- How to handle auto-classification from the drawing code? E.g. do you create a new (additional) classification, or (all?) replace
- existing classifications?
Detail
No problems determined until now. A smarty loop goes through all Classifications records to display them line to line.
New/Update
For every aspects defined in table Aspects at least one line appears even if it is empty. At the right side of all line there is a new button to open additional line for entering classification in the same aspect, and a delete button to remove that classification. If there is no more classification in an aspect (after deleting the last one) an empty line appears.
aspect X |
code |
AX_L1_0 |
AX_L2_0 |
... |
from - to |
new/delete |
|
code |
AX_L1_1 |
AX_L2_1 |
... |
from - to |
new/delete |
Search
Searching is a performance issue. Because of all Classifications are different records a large joins could be used to perform searching, which can be very slow. The following optimization steps will be implemented:
determine first the number of Classifications records involved in one aspect value search
- perform a nested select with the smallest records set in the inner most level to limit the involved records to the minimum. The result should be saved into a temp table in the database. This temp table should be deleted at every new search or list.
read DrawingsRevisionsJoinSet with the id set got from the select above
E.g.: assumed that we are looking for documents with aspect codes 22, 345 and 42, the steps above:
1. select code, count(*) from Classifications where code in ( '22', '345', '42' ) order by 2; +------+----------+ | code | count(*) | +------+----------+ | 345 | 10 | | 42 | 234 | | 22 | 1410 | +------+----------+ 2. select objectId from Classifications where objectTypeId = ... and code = '22' and object Id in ( select objectId from Classifications where objectTypeId = ... and code = '42' and object Id in ( select objectId from Classifications where objectTypeId = ... and code = '345' ) )
List
Displaying of classifications in a document list is also a performance issue. To be able to display classification information quickly a static database table will be used to store some information about classified documents:
AspectCache Table
Object Id |
Object Type |
aspect 0 |
... |
aspect 9 |
||||||||||||
|
|
min code |
max code |
full code |
hoverText |
count |
from |
to |
... |
min code |
max code |
full code |
hoverText |
count |
from |
to |
There is one record for one object (Drawing, Task). The field full code is a comma separated list of all aspect values in the appropriate aspect assigned to the object. On a document list with classifications the min code, max code can appear according the sorting order. On a non-sorted list the full code can appear or it can be a site setting parameter.
Issue
The AspectCache table can be updated:
- database procedures on regularly basis (cron?)
- fired by triggers on the tables Drawings, Comments and Classifications
- by application transactions
Listing Multiple Classification Values
Three cases are possible:
- One classification, with a single from-to pair (E.g. one chainage range on a single alignment)
Display: Code x->y -- or code only, with no values?
Hover: Name x->y
- Multiple classifications on same classification, with different from-to pairs (e.g. multiple chainage ranges on a single alignment)
Display: Code min-x -> max-y...
Hover: Name min-x -> max-y (multiple)
- Multiple classifications on different classification, with different from-to pairs (e.g. multiple chainage ranges on multiple alignments)
Display: Code-mix, Code-max... -- Or can we display something more sensible?
Hover: Name-min, Nam-max...(multiple)
We don't need to make a decision now, as the display only changes the update that fills the aspect cache table.