Class RestrictionParsingHelper
This class implements an infix-to-binary-expression-tree parser, so that the expansions of ArchiveRestrictionInfos can be made into a proper SQL Restriction.
Inherited Members
Namespace: SuperOffice.CRM.ArchiveLists
Assembly: SoDataBase.dll
Syntax
public class RestrictionParsingHelper
Remarks
Processing (a = 2 OR b = 3) AND (c = 4 OR d = 5) kind of restrictions is done by letting each provider component handle individual restrictions ('atoms'), i.e., a = 2 above. However, instead of appending them directly to the main query using RestrictionAnd like today, the individual expansions (of type Restriction) will instead be put "on hold" in the ArchiveSelect, and left for later processing.
This class comes in when that "later processing" is done - it will parse the original ArchiveRestrictionInfo[] and extract from it the main structure, such as (restriction OR restriction) AND (restriction OR restriction) from the example above. It will then combine the structural tree (which handles AND, OR and parentheses) with the individual expansions of each ArchiveRestrictionInfo, and create a final Restriction which contains both. The algorithm is a standard infix to binary tree conversion, preceded by a step that converts the rather mixed representation of and ArchiveRestrictionInfo into a stream of tokens that are easier to work with; and there is a lookup to get hold of the expansion of each restriction. If an expansion is missing, then that restriction is ignored - this means that the ArchiveRestrictionInfo either did not result in an expansion, or that it was hard-appended to the query; we assume that this was done for a good reason.The final return value may be null, since empty restriction sets (or no valid expansions) is a valid case. Reference: http://www.cs.utexas.edu/users/lavender/courses/EE360C/lectures/lecture-24.pdf - this is a well-written and concise reference to the algorithm used. Basic second-year CS stuff, really...
Constructors
RestrictionParsingHelper()
This class implements an infix-to-binary-expression-tree parser, so that the expansions of ArchiveRestrictionInfos can be made into a proper SQL Restriction.
Declaration
public RestrictionParsingHelper()
Remarks
Processing (a = 2 OR b = 3) AND (c = 4 OR d = 5) kind of restrictions is done by letting each provider component handle individual restrictions ('atoms'), i.e., a = 2 above. However, instead of appending them directly to the main query using RestrictionAnd like today, the individual expansions (of type Restriction) will instead be put "on hold" in the ArchiveSelect, and left for later processing.
This class comes in when that "later processing" is done - it will parse the original ArchiveRestrictionInfo[] and extract from it the main structure, such as (restriction OR restriction) AND (restriction OR restriction) from the example above. It will then combine the structural tree (which handles AND, OR and parentheses) with the individual expansions of each ArchiveRestrictionInfo, and create a final Restriction which contains both. The algorithm is a standard infix to binary tree conversion, preceded by a step that converts the rather mixed representation of and ArchiveRestrictionInfo into a stream of tokens that are easier to work with; and there is a lookup to get hold of the expansion of each restriction. If an expansion is missing, then that restriction is ignored - this means that the ArchiveRestrictionInfo either did not result in an expansion, or that it was hard-appended to the query; we assume that this was done for a good reason.The final return value may be null, since empty restriction sets (or no valid expansions) is a valid case. Reference: http://www.cs.utexas.edu/users/lavender/courses/EE360C/lectures/lecture-24.pdf - this is a well-written and concise reference to the algorithm used. Basic second-year CS stuff, really...
Methods
GenerateSqlRestrictionFromExpansions(ArchiveRestrictionInfo[], Dictionary<ArchiveRestrictionInfo, Restriction>)
Combine an array of ArchiveRestrictionInfo objects with their corresponding expansions into individual Restriction objects, into a properly structure Restriction that takes operator precedence and parentheses into account. See class remarks for details.
Declaration
public Restriction GenerateSqlRestrictionFromExpansions(ArchiveRestrictionInfo[] restrictions, Dictionary<ArchiveRestrictionInfo, Restriction> expansion)
Parameters
Type | Name | Description |
---|---|---|
ArchiveRestrictionInfo[] | restrictions | Original restriction array |
Dictionary<ArchiveRestrictionInfo, Restriction> | expansion | Expansion dictionary, presumably from an ArchiveSelect |
Returns
Type | Description |
---|---|
Restriction | Complete, structured Restriction - or null, if there were no expansions (this is quite legal) |
Remarks
Processing (a = 2 OR b = 3) AND (c = 4 OR d = 5) kind of restrictions is done by letting each provider component handle individual restrictions ('atoms'), i.e., a = 2 above. However, instead of appending them directly to the main query using RestrictionAnd like today, the individual expansions (of type Restriction) will instead be put "on hold" in the ArchiveSelect, and left for later processing.
This class comes in when that "later processing" is done - it will parse the original ArchiveRestrictionInfo[] and extract from it the main structure, such as (restriction OR restriction) AND (restriction OR restriction) from the example above. It will then combine the structural tree (which handles AND, OR and parentheses) with the individual expansions of each ArchiveRestrictionInfo, and create a final Restriction which contains both. The algorithm is a standard infix to binary tree conversion, preceded by a step that converts the rather mixed representation of and ArchiveRestrictionInfo into a stream of tokens that are easier to work with; and there is a lookup to get hold of the expansion of each restriction. If an expansion is missing, then that restriction is ignored - this means that the ArchiveRestrictionInfo either did not result in an expansion, or that it was hard-appended to the query; we assume that this was done for a good reason.The final return value may be null, since empty restriction sets (or no valid expansions) is a valid case. Reference: http://www.cs.utexas.edu/users/lavender/courses/EE360C/lectures/lecture-24.pdf - this is a well-written and concise reference to the algorithm used. Basic second-year CS stuff, really...