Static Public Member Functions | |
_.Library.Status | CreateDomainTables (_.Library.Integer pDomainId, _.Library.String pPackageName, _.Library.String pRefClass, _.Library.List pMetadata, pAdditionalIndices, _.Library.String pGlobalPrefix, _.Library.Boolean pOverWrite, _.Library.Boolean pQueue) |
_.Library.Status | DropDomainTables (_.Library.String pPackageName) |
Drops any classes generated by <method>CreateDomainTables</method> in package pPackageName More... | |
_.Library.Status | SyncCustomizations (_.Library.Integer pDomainId, _.Library.String pPackageName, _.Library.Boolean pAutoPurge, _.Library.Integer pStartSrcId, _.Library.Integer pEndSrcId, pRanges) |
Either pDomainId or pPackageName has to be passed in, or both if they are known. | |
The InterSystems IRIS NLP iKnow technology is now deprecated. Please see the product documentation for more detail.
This class is used to generate and manage SQL projections of iKnow data structures for a particular domain. The easiest way to generate these SQL projections is by setting the objectsPackage attribute on the <domain> element in a Domain Definition.
These projections can be customized in any of the following ways:
The CustomAnnotations table is special in the sense that it's the only table that can be written to directly. It allows users to specify custom annotations for specific sentence parts (Part table), which will be available through the Annotations property of that Part table, next to attributes and matching results.
The following modifications are NOT supported:
These table projections and any associated data will be dropped when dropping the domain.
It is important to note that the generated projections include a number of denormalizations, such as calculated fields providing convenience access to data stored in another table. For example, the EntityValue property of the Part table is a calculated field based on the string value of the corresponding EntityUnique record. This means filtering or grouping by such denormalized columns directly may lead to valid but not necessarily efficient SQL. Therefore, it is recommend to check query plans and, when adopting the queries for production use (or when implementing a query generation utility), ensure appropriate indices will be used, either custom (as explained earlier) or default ones by adding a query subclause.
When generating these tables, the actual classes, properties and indices generated will be based on the Build Flag settings and some domain parameters (most importantly $$$IKPSTEMMING). If these would change (which already assumes the domain is empty), the GenerateDomainTables() method should be re-invoked.
|
static |
Creates a set of tables representing the data in domain pDomainId in package
pPackageName. If pOverWrite=1, existing table definitions will be overwritten, which may therefore no longer preserve non-calculated custom field values.
If pRefClass is non-null, a "Ref" property of that type will be added to the Source class, initialized with the value of its LocalReference property (ie, the ID field used when loading from a SQL table).
Any metadata fields referenced in pMetadata will be added to the Source class as calculated fields, along with indices mapping the corresponding iKnow data structures where possible.
A list of additional indices to be created can be supplied through pIndices in the following format:
pIndices("<i>TableName</i>", "idx", "<i>IndexName</i>") = $lb("<i>Properties</i>", "<i>IndexType</i>")
For the Source table, these can be references to pRefClass columns by using arrow syntax.
|
static |
Drops any classes generated by <method>CreateDomainTables</method> in package pPackageName
and associated customization data (field values & indices)