Multi-Application - jhId

12003

1. Background

• When is it necessary for multiple applications to use a single database?

Using a single database for multiple applications is suitable for scenarios that require data sharing, maintaining consistency, simplifying development and maintenance processes, facilitating data querying and analysis, resource sharing, integrated development and deployment, and reducing costs. This approach helps ensure data consistency across different applications, enhances overall system maintainability and collaboration, while lowering hardware and maintenance costs, and promoting the modularization and overall integration of business processes.

Taking the SEO project of JianghuJS as an example, we can illustrate more specifically the situation of multiple applications using a single database. The SEO project is divided into two modules: SEO Frontend Demonstration and SEO Backend Management. Both modules use the same database, and here are some specific examples:

1. User Data:
   In this project, user data is shared between the frontend demonstration and the backend management modules. For instance, the account information registered by users in the frontend demonstration module can also be utilized by the backend management system, including username, password, etc.

2. Article Data:
   The SEO project typically involves managing a large number of articles, and this article data needs to be shared between the frontend demonstration and backend management. Whether it is the article list displayed on the frontend or the article management in the backend, both are based on the same article table in the database.

3. Category and Tag Data:
   The category and tag information of articles may need to be used in both the frontend demonstration and backend management. This information can be shared in the same database's category and tag tables.

4. Site Configuration Information:
   Constant configuration information for the website, such as title, logo, footer information, etc., usually needs to remain consistent between the frontend demonstration and backend management. This configuration information is stored in the same database's configuration table.

5. Material Data:
   Material data such as images, files, audio, and video may need to be used in both the frontend and backend. By using the same database, these materials can be conveniently managed to ensure their consistency across various modules.

6. Template Page Data:
   The template data required for dynamically generated pages may need to be shared between the frontend and backend. This data can be stored in the same database's template table.

These examples illustrate that there is a need for data sharing and association between the frontend demonstration and backend management modules in the SEO project. Therefore, choosing to share a single database can better meet these needs. This practice simplifies data management and maintenance, enhancing the overall consistency of the system.

2. Configuration in config

• Configuration Method

In the config.local.example.js file, the configuration for jianghuConfig is as follows:

    jianghuConfig:{  
      jhIdConfig: {  
        // Whether to enable  
        enable: false,  
        // The jhId used by the current application, which will automatically filter using this jhId when using the configuration table  
        jhId: 'mingding_seo',  
        // Configuration tables that use jhId, generally keep the default  
        careTableViewList: [  
          '_cache',  
          '_constant',  
          '_file',  
          '_group',  
          '_page',  
          '_record_history',  
          '_resource',  
          '_resource_request_log',  
          '_role',  
          '_test_case',  
          '_ui',  
          '_user',  
          '_user_group_role',  
          '_user_group_role_page',  
          '_user_group_role_resource',  
          '_user_session',  
          '_view01_user',  
        ],  
      },  
    },  

• Configuration Property Description

For the configuration items of the JianghuJS framework, the jhIdConfig is used for multi-application identification. The specific properties are as follows:

• enable: Whether to enable the jhId feature, determining whether to activate multi-application identification.
• jhId: The jhId used by the current application, i.e., the project identifier, used to distinguish different applications.
• careTableViewList: A list of configuration tables that use jhId; these configuration tables will be filtered based on the application's jhId to ensure data isolation.

3. Database Configuration

• jhId

In a multi-application system, if different applications need to share the same database, to ensure data isolation, it is necessary to introduce an identifier in the data table to mark which application the data belongs to. This is the role of jhId, which acts as this identifier in the JianghuJS framework. Specifically, using jhId can achieve the following functions:

1. Data Isolation: The data of different applications is identified by jhId, ensuring that under the condition of a shared database, the data of each application does not interfere with each other.

2. Multi-Application Coexistence: Allows storing data from multiple applications in the same database, distinguishing them through jhId.

3. Configuration Filtering: When using configuration tables and other functions, the system can filter based on the current application's jhId, ensuring that the retrieved configuration is relevant to the current application.

In the configuration, you can enable the jhId feature, specify the jhId used by the current application, and define the list of configuration tables that use jhId. This way, the framework can automatically handle jhId-related database operations based on these configurations, thus meeting the needs of multi-application data management.

• Conflict Handling (Separated into Business Tables)

In JianghuJS data configuration, it is divided into configuration tables and business tables. Configuration tables manage system configurations, caching, permission management, etc., and typically do not involve specific business data, but are more used for the operation and auxiliary functions of the framework. Business tables are responsible for managing business data.

• Configuration Tables: Used to manage system configuration information, including system constants, cache settings, permission management, etc. These tables usually do not store specific business data but are used to support the operation of the system and various functions.

• Business Tables: Responsible for managing actual business data, such as articles, user information, file management, etc. Each business table has a clear definition and purpose, used to store and process specific business logic.

In both configuration tables and business tables, jhId is used as a filtering identifier. By adding the jhId field to all tables and using this field for filtering during queries and operations, data isolation can be achieved, and data conflicts between different applications can be avoided. Specific practices include:

1. Data Isolation: Adding the jhId field to each table ensures that each record is associated with a specific application. This way, the data of different applications can coexist in the same table, but through jhId filtering, they are logically independent.

2. Query Filtering: When performing data queries, always filter by jhId to ensure that only data belonging to a specific application is returned. This simplifies the query logic, allowing each application to see only the data it cares about.

3. Data Insertion and Update: When inserting and updating data, always set the correct jhId to ensure that the new data is associated with the specific application.

4. Permission Control: In the system, jhId can be used for permission control, ensuring that each user can only access the data belonging to their application.

4. Logical Explanation

• Handling of jhId in JianghuKnex

In JianghuKnex, the handling of jhId is mainly reflected in the support for multi-application data isolation. Here are the key points regarding the handling of jhId:

1. Initialization of jhId Configuration:
   During the initialization process of JianghuKnex, you can specify whether to enable jhId support and related configuration information through configuration items.

// Example configuration  
const jianghuConfig = {  
  jhIdConfig: {  
    // Whether to enable  
    enable: true,  
    // The jhId used by the current application, which will automatically filter using this jhId when using configuration tables  
    jhId: 'example_app',  
    // Configuration tables that use jhId, generally keep the default  
    careTableViewList: [...],  
  },  
};  

const knex = require('knex')({  
  // ...other configurations  
  jianghuConfig,  
});  

2. Table-Level jhId Filtering:

JianghuKnex will automatically filter based on the configured jhId when executing queries, ensuring that the queried data belongs to the current application.

const result = await knex('example_table').where({ /* ... */ }).select();  

3. Column-Level jhId Handling:

JianghuKnex also supports jhId handling for columns in the table, for example, automatically adding a jhId column to the table or automatically including jhId conditions when performing operations.

// Example: Adding jhId column to the table  
await knex.schema.table('example_table', (table) => {  
  table.string('jhId', 255).after('id');  
});  

// Example: Automatically including jhId conditions when executing queries  
const result = await knex('example_table').where({ /* ... */ }).select();  

Overall, JianghuKnex integrates and encapsulates jhId in its underlying implementation, allowing developers to easily achieve multi-application data isolation needs by simply configuring the relevant options.