What Data for This Category Looks Like
The core data for this category originates from product 3D models and GD&T specifications, process route documents, coordinate measuring machine data, on-site trial feedback, and metrology system records. Daily generated documents include tooling requirement specifications, positioning datum schemes, fixture design drawings, gauge operation instructions, acceptance reports, calibration records, and change histories. Data updates are conducted on a per-project basis, triggered by product changes or periodic calibration actions. Each single update is linked to the full lifecycle node information of one set of tooling or gauge.
Constraints Imposed by These Characteristics on Deployment and Upgrade
Documents for this category are mostly structured engineering drawings and metrology records. Data updates are tied to individual project nodes. During deployment, access formats for multi-source heterogeneous data must be supported. Since data updates are triggered by projects and changes, the upgrade process must preserve historical project document indexes. This prevents calling invalid old data during bidding. Additionally, the volume of associated data for a single set of tooling accumulates gradually as the project advances. Deployment storage and indexing resources must reserve sufficient expansion capacity to avoid retrieval delays caused by growing data volumes.
How to Set Configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
STORAGE_S3_ENDPOINT | http://internal object storage IP:9000 | Drawings, calibration records and other files for tooling and fixtures must be stored in an internally accessible object storage, matching existing enterprise operation and maintenance habits |
REDIS_URL | redis://:{custom password}@redis service address:6379/0 | Used to cache retrieval results of bid documents and temporary session data. The default database 0 can isolate service data |
PG_URL | postgresql://{database username}:{database password}@pg service address:5432/fastgpt_tooling | Stores project-related bid documents, quotation data, and tooling change histories. A dedicated database avoids conflicts with other service data |
ROOT_KEY | 32-character random string | Used for system internal interface authentication, ensuring access security of sensitive bid-related data |
DB_MAX_LINK | 20 | Adapts to the concurrent retrieval requirements of multiple documents per single project for this category, preventing database connection exhaustion |
Three Common Misconfigurations
- Symptom: After upgrading to FastGPT v4.17.0, an error "Failed to create post presigned url" appears when uploading fixture design drawings or calibration record files. Cause:
STORAGE_S3_ENDPOINTand associated storage keys are not configured properly, so the object storage cannot generate pre-signed upload links. - Symptom: After migrating deployment, previously existing project tooling documents cannot be retrieved. Cause: The PostgreSQL database linked to
PG_URLand cache data linked toREDIS_URLwere not migrated synchronously, leading to loss of historical indexes. - Symptom: A "worker terminated due to reaching memory limit" error occurs when creating a bid document knowledge base. Cause: The
DB_MAX_LINKparameter was not adjusted. Concurrent retrieval uses too many database connections, exceeding the server's memory allocation threshold.
How to Verify Proper Configuration
- Run a single-file upload test: Upload the design drawing of a single fixture set, confirm no pre-signed link errors occur, and the file can be stored normally and linked to the corresponding project.
- Import change history data from existing project tooling, use the knowledge base retrieval function to verify that associated documents can be returned normally.
- Launch a batch concurrent retrieval test: Call 5 retrieval requests at the same time, confirm no memory overflow or connection exhaustion errors occur.
- Check the
ROOT_KEYconfiguration, use internal interface calls to test the authentication logic, confirm that sensitive interfaces correctly block unauthorized access.
The values provided are common starting points and should be evaluated against the reader's own samples.