Data Initialization
Continue from database and middleware deployment. This page applies to a new business database for a first installation. MySQL, Redis, and Neo4j must already be running and have passed connection checks.
1. Pre-initialization checks
Prepare qOntology source or a deployment package from the same release as the backend JAR and frontend resources. This page uses both files below; show in the filename does not mean all business tables can be skipped:
docker/qOntology/mysql/init/
├── init-system.sql # System management, permissions, and related base tables
└── init-show.sql # Ontology, application, model tables, and initial dataIn the inspected version, both scripts create and use the qontology database. Each contains 32 tables, with no overlapping names. Check the corresponding package for later releases; 64 tables is not a fixed requirement for all versions.
Do not replay against an existing business database
Both SQL files contain DROP TABLE IF EXISTS. Reimporting deletes and recreates the affected tables; it is not a way to fix general startup errors or perform upgrades. If the database exists, confirm it is empty and prepared for this deployment. Stop this first-time initialization workflow if it contains business data.
Run from the source root on the server. Check only that the files exist; do not execute release or reset scripts:
# Enter the matching source directory and check both initialization scripts
cd /path/to/qOntology
test -f docker/qOntology/mysql/init/init-system.sql
test -f docker/qOntology/mysql/init/init-show.sql
# Log in to MySQL and check whether the target database is empty
/opt/mysql57/bin/mysql --defaults-file=/etc/mysql57.cnf -uroot -pAfter entering MySQL, check:
SHOW DATABASES LIKE 'qontology';
SELECT COUNT(*) AS existing_tables
FROM information_schema.tables
WHERE table_schema = 'qontology';
EXIT;A new environment should have no business tables yet. If tables exist, do not continue with the import commands below.
2. Initialize the MySQL business database
2.1. Import in order
Stay in the source root and enter the MySQL administrator password when prompted for each command. Run the second command only after the first succeeds. Do not add --force to ignore errors:
# First installation into an empty database only: import system tables and base data
/opt/mysql57/bin/mysql --defaults-file=/etc/mysql57.cnf -uroot -p \
< docker/qOntology/mysql/init/init-system.sql# After the system script succeeds, import business tables and initial data
/opt/mysql57/bin/mysql --defaults-file=/etc/mysql57.cnf -uroot -p \
< docker/qOntology/mysql/init/init-show.sqlThe scripts include CREATE DATABASE and USE qontology, so there is no need to select the business database beforehand. Do not additionally import latest初始化.sql, historical initialization SQL, or every file in an upgrade directory.
2.2. Create the application database account
Use an interactive administrator session to avoid putting the application password in Shell command arguments:
# Log in as administrator without saving MySQL command history for this session
MYSQL_HISTFILE=/dev/null /opt/mysql57/bin/mysql --defaults-file=/etc/mysql57.cnf -uroot -pReplace the password before executing. This account is limited to local access to qontology and receives no global administration privileges:
CREATE USER 'qontology'@'127.0.0.1' IDENTIFIED BY '<MYSQL_APP_PASSWORD>';
GRANT ALL PRIVILEGES ON qontology.* TO 'qontology'@'127.0.0.1';
SHOW GRANTS FOR 'qontology'@'127.0.0.1';
EXIT;If the account already exists, investigate its origin; do not delete it just to repeat this step. The API will use 127.0.0.1:3306, database qontology, username qontology, and the password set here.
2.3. Verify tables and credentials
Log in with the application account over TCP:
/opt/mysql57/bin/mysql --protocol=TCP -h127.0.0.1 -P3306 -uqontology -p qontologySHOW TABLES;
SELECT COUNT(*) AS system_users FROM system_user;
SELECT COUNT(*) AS system_roles FROM system_role;
SELECT COUNT(*) AS ontology_tables
FROM information_schema.tables
WHERE table_schema = DATABASE() AND table_name LIKE 'om\_%';
EXIT;Confirm that both system and business tables exist and queries produce no permission or encoding errors. Obtain the application administrator login and initial password from the matching release notes or delivery records; they cannot be inferred from the database password. Check model, connection, and sample records in the scripts against your environment before enabling them.
3. Neo4j initialization and verification
3.1. Start with a new empty database
The first Neo4j startup on the previous page creates the default database. This page does not import unverified graph data. Log in with the credentials set previously:
JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 \
/opt/neo4j/bin/cypher-shell -a bolt://127.0.0.1:7687 -u neo4jRETURN 1 AS connection_ok;
SHOW DATABASES;
MATCH (n) RETURN count(n) AS node_count;Confirm that the default neo4j database is available. A new empty database normally has 0 nodes. Enter :exit to leave. Demo records in MySQL do not automatically create graph nodes; when using an empty graph, visible demo graphs are not a condition for successful initialization.
3.2. Optional sample graph data
sql/neo4j/data/ and docker/qOntology/neo4j-init/data/ in the source are data directories, not .dump files that can be passed directly to neo4j-admin load. This tutorial does not overwrite the new database or directly copy the system database and authentication files from those directories.
To restore a demo graph, obtain a supported export package and restoration instructions matching the release. Confirm the Neo4j version, database name, downtime requirements, and related relational data. Back up existing graphs, then follow the procedure for that export format. Without a known export package, keep the empty database rather than inventing an import path.
4. Validation and failure handling
| Check | Completion criteria |
|---|---|
| System and business tables | Both SQL scripts complete successfully and key tables can be queried |
| Application account | Can connect to 127.0.0.1:3306 and query qontology |
| Neo4j | Default database available; RETURN 1 succeeds |
| Release consistency | SQL, configuration, JAR, and frontend artifacts belong to the same release |
For SQL errors, record the file, line number, and error message without passwords or complete business data. Check MySQL version, file integrity, character sets, and permissions. Do not treat replaying all initialization scripts as a general repair. Upgrade existing deployments with the corresponding versioned scripts and confirm their execution order.
Next: application build. If matching built artifacts are already available, proceed directly to qOntology service deployment.
