Skip to end of metadata
Go to start of metadata

Currently (0.9.3), a Rice client application must include the KNS tables in their own database. There are a few issues with this, including (but not limited to):

  1. Results in 2 Document (DOC_HDR) tables, one in KNS, one in KEW
  2. Results in 2 Document Type (DOC_TYP) tables, one in KNS, one in KEW
  3. Since the KNS Document Types are stored in tables in the client application, this causes conflicts on the standalone server since there is only a single KEW document type table

List of KNS Tables

  1. KRNS_DOC_TYP_T
  2. KRNS_DOC_TYP_ATTR_T
  3. KRNS_DOC_HDR_T
  4. KRNS_MAINT_DOC_T
  5. KRNS_MAINT_DOC_ATT_T
  6. KRNS_MAINT_LOCK_T
  7. KRNS_ADHOC_RTE_ACTN_RECIP_T
  8. KRNS_LOOKUP_RSLT_T
  9. KRNS_LOOKUP_SEL_T
  10. KRNS_SESN_DOC_T
  11. KRNS_PESSIMISTIC_LOCK_T
  12. KRNS_ATT_T
  13. KRNS_NTE_T
  14. KRNS_NTE_TYP_T
  15. KRNS_NMSPC_T
  16. KRNS_PARM_DTL_TYP_T
  17. KRNS_PARM_T
  18. KRNS_PARM_TYP_T

Analysis of Tables

Document Header Table - KRNS_DOC_HDR_T

Where this table ends up will depend upon what we decide to do with Document Header. I'm inclined to say this gets moved to the standalone server and combined with KREW_DOC_HDR_T. However, do client applications need to query this data? Does it make sense to keep a table client-side with references to document ids?

Maintenance Document Tables - KRNS_MAINT_DOC_T, KRNS_MAINT_DOC_ATT_T, KRNS_MAINT_LOCK_T

These tables store info about maintenance documents including their XML content, attachments and outstanding locks.

I can't think of a specific reason to require these to live server-side (although they certainly could). I do believe the attachment store should be located in the client application so one could argue for KRNS_MAINT_DOC_ATT_T to live in the client DB. Still, see discussion on KRNS_ATT_T below.

It is also interesting to note that KRNS_MAINT_DOC_T could be eliminated if the XML was stored in the Document's XML content.

Adhoc Recipients - KRNS_ADHOC_RTE_ACTN_RECIP_T

I believe this is just a temporary table for storing adhoc recipients prior to routing of the document? If so then this table could be either client-side or server-side.

Lookups - KRNS_LOOKUP_RSLT_T, KRNS_LOOKUP_SEL_T

These tables are related to storing lookup results and selections. These can remain client-side.

Session Documents - KRNS_SESN_DOC_T

This table is for serializing documents that use http session. This can remain client-side.

Pessimistic Locks - KRNS_PESSIMISTIC_LOCK_T

This could live server or client side. This should probably be handled the same way as KRNS_MAINT_LOCK_T since they seem to be performing similar functions (unless I'm mistaken?)

Notes and Attachments - KRNS_ATT_T, KRNS_NTE_T, KRNS_NTE_TYP_T

Since notes are attached to documents, these tables should live wherever the document table lives (server-side). However, attachments should probably be stored in the client application (although it may be possible to support server-side attachment storage in the future if desirable). Having the table server-side but the files client-side might be confusing.

Namespace and Parameters - KRNS_NMSPC_T, KRNS_PARM_DTL_TYP_T, KRNS_PARM_T, KRNS_PARM_TYP_T

The namespace table stores namespaces while the parameter tables store system parameters. These can be moved server-side, however some refactoring may need to be done to deal with "global" system parameters which should really be configurable on a per-application basis.

Summary

Tables which can move server-side

  1. KRNS_NMSPC_T
  2. KRNS_PARM_DTL_TYP_T
  3. KRNS_PARM_T
  4. KRNS_PARM_TYP_T

Tables which should remain client-side

  1. KRNS_DOC_HDR_T
  2. KRNS_LOOKUP_RSLT_T
  3. KRNS_LOOKUP_SEL_T
  4. KRNS_SESN_DOC_T
  5. KRNS_ATT_T
  6. KRNS_MAINT_DOC_T
  7. KRNS_MAINT_DOC_ATT_T
  8. KRNS_MAINT_LOCK_T
  9. KRNS_NTE_T
  10. KRNS_SESN_DOC_T
  11. KRNS_ADHOC_RTE_ACTN_RECIP_T
  12. KRNS_PESSIMISTIC_LOCK_T

Tables which can be dropped

  1. KRNS_NTE_TYP_T
  • No labels