Major bug fixes relating to the Redis implementation in Reprocessing and Search Key Cache were identified and fixed as part of the rekeying development. Included functionality to stop the Exhaustive training. Fixed the Unsupervised learning functionality in Exhaustive Training. Embedded the Mock Data CSV data into a class to make it compatible with Docker without needing to modify the Dockerfile (i.e, build). Included a new table that stores training data to enhance support capabilities for Exhaustive. Reintroduced and validated the Multitenancy functionality. Postgres is now fully deprecated in place of Redis for cache, and all implementations of the Interfaces for Postgres have been removed. No migrations exist to support this deprecation, and Postgres as a cache is now wholly unsupported. Removed the Indexing background thread, as Redis does not require it, given that it is a key-value pair database. Created a RedisCommandFlag Environment Variable to support Fire and Forget write to Redis in Invocation. Implemented functionality to Export, Peek and Download configuration environments using a secure, encrypted scheme. Created a permission to access the functionality via the user interface. Extensive database-based logging is included to provide for a comprehensive audit. Created functionality to Import the encrypted Export file inside a database transaction to ensure consistency. As Docker is now the primary deployment model, log4net instantiation has been moved to an approach that primarily uses programmatic instantiation of the ConsoleLogger and RollingFileAppender given Environment Variables. Implemented functionality to support remote \ mounted Log4Net XML Serialisation files for more advanced log4net configurations. Reintroduced access to counters via the user interface and created a permission. Took the opportunity to implement ReSharper linter suggestions. Disabled the Lock button across the whole application, with that functionality being reserved for future use. It is intended that locking happens programmatically on the basis of dependencies in future commits. Fixed several significant end-use bugs which became apparent during testing of the refactored code relating to case management and visualisations. Fixed certain other minor bugs that came up during testing. Brought documentation up to date for this commit. Brought the Docker Compose file up to date for this commit. Removed Redundant Environment Variables for this commit. Made the README file less verbose and unnecessary.
3.4 KiB
layout, title, nav_order, parent
| layout | title | nav_order | parent |
|---|---|---|---|
| default | Parent Objects | 3 | Navigation |
🚀Speed up implementation with hands-on, face-to-face training from the developer.
Parent Objects
To Create, Update and Delete a parent object, in this example a Model, a similar user interface exists to list, expand upon then edit entries.
For example navigate to Models >> Model:
Models will be presented as a list of names:
To select into a Model, click on the link by name:
On clicking the link by name, the entry will be expanded upon:
Scrolling down the page and clicking on the back button will restore the view back to the list of models, as start of this procedure:
To Add a record to an object, a button titled New is implemented below the list of available models:
Clicking on this button will expand an empty model record:
Upon completing the form with valid values for this object (each of these is documented elsewhere), to commit the record, click the Add button after scrolling down to the base of the page:
If Add has been clicked, the version, created date and a guid (in some instances) will be returned by way of confirmation:
Alternatively, clicking the Back button will roll back the change and return to the list:
To update an entry, select into the entry from the list of names as if to view:
The fields are available for modification with the current values presented:
Upon completing the form with valid values for this object to commit the record, click the Update button after scrolling down to the base of the page. If Update has been clicked, the version and created date will be returned by way of confirmation, but any Guid will remain static:
The Back button should be used to return to the model list, which will expose the newly created entry:
To delete an entry instead of clicking the Update button, click the Delete button instead:
A message for confirmation will be sought:
Clicking ok will enact the delete, thereafter returning to the model list, having the same effect as clicking back, albeit without the entry just deleted available:
Each parent object entry will have a Name field, which is a text string. A description field appears on a more irregular basis and is a character string.
Upon update a copy of the record before the update is stored in a Version table in the database for the purpose of audit, thereafter the record is updating in place, incrementing the version number.
For example, on inspection of the versioning for Case Workflow Status Definitions:
select *
from "EntityAnalysisModelVersion"
Order By "Id" desc
It can be seen that a full copy of the record was taken before it was updated. Parent records are versioned in this manner such is the extent to which complex relationships exist, where Id must be immutable. It should be noted that there is a record for each update maintained in the database for the purposes of audit.













