You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a fundamental issue here having to do with how relationships are represented, or rather how they are not. There is currently an isSilence property as well as a Silence requirement type.
To support the workbox, many requirements have a follows property that links to the ParsedRequirement that introduces it.
This property is duplicated across a number of subclasses of Requirement explicitly as a reference to ParsedRequirement as the ORM won't let this be handled in the abstract class even though it's supposed to be a generic relationship and not hardcoded to this subtype.
There is no Requirement table. So I can't query for all requirements directly.
The generated query for loading the workbox is massive:
Note the execution time: [took 21 ms, 25 results] and the fact that not all requirement types are represented.
This is in part a consequence of choosing the Table Per Concrete Class (TPCC) Inheritance Strategy. This approach seems to prevent a straightforward representation of requirement relations such as X disjoins Y, X contradicts Y, X follows Y, etc.
By migrating to a Single Table Inheritance strategy, and introducing a Relation table for inter-requirement relations, this will solve many problems and open up more expressiveness in general. I suspect a significant reduction in code size as well and fix some other downstream hacks and awkwardness in the code
The text was updated successfully, but these errors were encountered:
There is a fundamental issue here having to do with how relationships are represented, or rather how they are not. There is currently an
isSilence
property as well as aSilence
requirement type.To support the workbox, many requirements have a
follows
property that links to theParsedRequirement
that introduces it.This property is duplicated across a number of subclasses of
Requirement
explicitly as a reference toParsedRequirement
as the ORM won't let this be handled in the abstract class even though it's supposed to be a generic relationship and not hardcoded to this subtype.There is no
Requirement
table. So I can't query for all requirements directly.The generated query for loading the workbox is massive:
Note the execution time:
[took 21 ms, 25 results]
and the fact that not all requirement types are represented.This is in part a consequence of choosing the Table Per Concrete Class (TPCC) Inheritance Strategy. This approach seems to prevent a straightforward representation of requirement relations such as
X disjoins Y
,X contradicts Y
,X follows Y
, etc.By migrating to a Single Table Inheritance strategy, and introducing a
Relation
table for inter-requirement relations, this will solve many problems and open up more expressiveness in general. I suspect a significant reduction in code size as well and fix some other downstream hacks and awkwardness in the codeThe text was updated successfully, but these errors were encountered: