Common FAQ for Data Models
Overview of Basic Capabilities for Data Models
Name
The data model name is a Chinese name provided to developers, does not need to be unique in the environment, and is primarily used to help developers identify their own data models.
Identifier
The data model identifier is used to denote a unique English ID within the current environment. It is utilized across multiple modules including the editor, OPENAPI, and APIS.
Status
Preview and Production
A data model is associated with two underlying physical tables: the preview table and the production table. The preview table is used for development and debugging, while the production table contains real production data.
Why Publish?
The underlying implementation of the data model is divided into two states: preview and release. These two states are physically isolated, meaning data is not shared between them. The preview status primarily allows developers to perform rapid development, quickly adjust component styles, and test data-related interfaces. The production state requires publishing the data source. At this stage, basic development is considered complete, requiring only minor adjustments before going live. Data will be written to the production environment and undergo the full process within the WeDa functional module.
Data Model Client-Side Capabilities
The underlying implementation of the data model is divided into: FlexDB, Mysql Due to the implementation differences in the two database capabilities, the WeDa APIs vary accordingly.
MongoDB has weaker association capabilities but excels in array and object queries. Mysql has strong association capabilities.
Data Model HTTP-API
Data Model Underlying Database
The underlying data model database enabled by default in WeDa is a shared-type Mongo database, suitable for small to medium-scale business scenarios with low concurrency. Higher-tier plans can enable dedicated Mysql databases, suitable for medium to large-scale businesses with high concurrency demands.
Slow Data Model Queries
WeDa essentially shields customers from the underlying database, aiming to help developers develop quickly while also weakening the storage functions often required in software development. When the business scale expands and data volume increases, the query speed will significantly slow down. In this case, it is recommended that developers create an index.
FlexDB Database
The FlexDB database essentially relies on CloudBase's cloud database. You need to first locate the cloud database.
Return to the old console.
Locate your environment based on the environment id.
Locate the cloud database
Create required indexes based on the data model identifier.
lcap-dataxxx-xxx-preview is the preview table lcap-dataxxx-xxx is the production table
Warning: This operation involves the underlying database. Any create, read, update, or delete operations on table data will affect WeDa functionality. Do not delete any tables starting with lcap, otherwise it will cause the WeDa data model to become unavailable.
Mysql Database
Please operate your own database in the console.
How to Clear WeDa Model Data
FlexDB Database
Locate your own cloud database.
Write code in the console to clean up your own data tables.
For how to write code, please refer to Cloud Database Deletion Reference
Mysql Database
Please operate your own database in the console.