Top-level router for Exasol work. Use for any Exasol database, exapump, SQL, BucketFS, extension, integration, UDF, Script Language Container, or Exasol Personal setup task, then route to the narrowest specialized Exasol skill.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Use this skill whenever the user asks about Exasol. The user does not need to know internal skill names. Treat /exasol <task> and natural-language Exasol requests as the public interface.
Choose the narrowest skill whose front-matter description matches the request.
When several match, apply the precedence rules below; when several genuinely
apply, load them in dependency order.
Cloud Storage Extension over native import and export. When a request
mentions FROM SCRIPT CLOUD_STORAGE_EXTENSION, INTO SCRIPT CLOUD_STORAGE_EXTENSION, CLOUD_STORAGE_EXTENSION.IMPORT_PATH, or
CLOUD_STORAGE_EXTENSION.EXPORT_PATH, prefer
exasol-cloud-storage-extension over exasol-import or exasol-export.
Object-storage formats that only the extension reads. When a request
mentions importing Avro, ORC, or Delta from object storage such as S3,
Azure Blob Storage, Azure Data Lake, Google Cloud Storage, HDFS, or Alluxio,
prefer exasol-cloud-storage-extension unless the user clearly asks for
native IMPORT. Native import handles CSV, FBV, and Parquet; it does not read
those three formats, so a description match on "import from S3" alone routes
the request wrongly.
Import and export over general database work. When a request mentions
IMPORT, IMPORT INTO, or exapump upload, prefer exasol-import over
exasol-database even if the wording also contains generic terms such as
SQL or query. When it mentions EXPORT, EXPORT INTO, or exapump export,
prefer exasol-export the same way. A bare CREATE CONNECTION with no
import, export, or object-store file-movement intent belongs to
exasol-database.
Adapter development over adapter use. When a request mentions custom
virtual schema adapter implementation, source-specific JDBC dialect code,
custom document-file adapter code, virtual-schema-common-jdbc, adapter JAR
packaging, custom adapter properties, type mapping, pushdown capabilities,
metadata reader behavior, or adapter-side remote debugging, prefer
exasol-virtual-schema-adapter-development over
exasol-jdbc-virtual-schemas and exasol-document-virtual-schemas.
Document-file virtual schemas over JDBC virtual schemas. A virtual schema
over files in object storage — S3, Google Cloud Storage, Azure Blob Storage,
Azure Data Lake Storage Gen2 — is exasol-document-virtual-schemas. A
virtual schema over a database source such as PostgreSQL, Oracle, MySQL, SQL
Server, or DB2 is exasol-jdbc-virtual-schemas. Do not route a bare
Virtual Schema mention to the JDBC skill unless the source is clearly
database-based; ask which source is meant instead.
Dedicated skills over the catalog. Route to exasol-extension-catalog
only when the primary intent is comparison, discovery, support-status research,
or architecture selection — "which tool should I use", "what are the options
for", "is this supported". A request that names a product, extension, or
integration and asks to execute, configure, or troubleshoot it goes to that
product's dedicated skill, not to the catalog. In particular, Text AI Extension
and TXAIE work goes to exasol-text-ai, and Transformers Extension work
goes to exasol-transformers. Once the catalog has helped the user choose,
hand off.
Container activation over container staging. Activating or building a
Script Language Container belongs to exasol-udfs — that covers the
SCRIPT_LANGUAGES activation statements, flavors, and container builds. Getting
the container, JAR, or model file into a bucket belongs to exasol-bucketfs. A
request that uploads and then activates needs both: exasol-bucketfs to
stage the file, then exasol-udfs to activate it.
Deployment intent is required for Exasol Personal. Route to
exasol-setup-personal only when the user wants to install, deploy, or set up
Exasol itself. A bare cloud-provider or storage token such as Azure Blob,
S3, or AWS is not deployment intent — those belong to the import, export,
and document virtual schema skills. Deployment intent alone does not settle
which skill: a Docker-based database on the current machine is
exasol-itde, while a Mac VM or a deployment into the user's own AWS, Azure,
Exoscale, or STACKIT account is exasol-setup-personal. When the user asks
only for a "local" database, ask which of the two is meant.
When setup and usage both apply, resolve prerequisites first:
/exasol <task> in examples.~/.exapump/config.toml. Use
the tool's own masking commands instead, such as
exapump profile show <name>.まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Exasol BucketFS file system management via the `exapump bucketfs` CLI. Covers listing, uploading, downloading, and deleting files and directories in BucketFS, the `bfsdefault` service and other bucket services, bucket structure, `bfs_*` profile settings, the `/buckets/<service>/<bucket>/<path>` UDF path, and staging JARs, models, and Script Language Containers for UDFs.
日本語の概要は準備中です。原文の説明を表示しています。
Use Exasol Cloud Storage Extension workflows for moving structured object-storage files through extension UDFs. Covers setup prerequisites, the fixed `CLOUD_STORAGE_EXTENSION.IMPORT_PATH` and `CLOUD_STORAGE_EXTENSION.EXPORT_PATH` entrypoints used with `FROM SCRIPT` and `INTO SCRIPT`, Parquet, Avro, ORC, and Delta files on S3, Google Cloud Storage, Azure Blob Storage, Azure Data Lake, HDFS, and Alluxio, connection-object credential patterns, and routing away from native IMPORT or EXPORT when the extension path is the right fit.
日本語の概要は準備中です。原文の説明を表示しています。
Exasol database interaction via the exapump CLI and Exasol SQL. Covers SQL queries and DML/DDL such as `SELECT`, `INSERT`, `UPDATE`, `DELETE`, `MERGE`, `CREATE TABLE`, `ALTER TABLE`, and `DROP TABLE`, `CREATE CONNECTION` connection objects without import or export intent, schema inspection, table design, `exapump sql` and `exapump profile`, query profiling, analytics, and Exasol-specific SQL behavior outside exasol-import and exasol-export.
日本語の概要は準備中です。原文の説明を表示しています。
Distributed machine learning, data mining, and iterative HPC with Exasol. Covers end-to-end ML pipelines (DISTRIBUTE BY + SET scripts + BucketFS), per-entity federated training with partial_fit and ctx.reset(), batch inference, map-reduce ensemble training, distributed ensemble and SON algorithm for frequent itemset mining (Apriori, FP-Growth, association rules, market-basket analysis), Lua execute script orchestration for iterative algorithms (k-means, SGD, gradient descent), scikit-learn model training, parallel hyperparameter search, per-entity forecasting, anomaly detection, model lifecycle in BucketFS (pickle/joblib/ONNX versioning), GPU acceleration via CUDA SLCs (PyTorch/TensorFlow/RAPIDS), and ML-specific performance tuning (skew, OOM, multi-pass chunking).
日本語の概要は準備中です。原文の説明を表示しています。
Use Exasol document-file virtual schemas for federated read-only access to object and file storage — S3, Google Cloud Storage, Azure Blob Storage, and Azure Data Lake Storage Gen2 document files. Covers document-file adapter family selection, the EDML `MAPPING` definition, `CREATE VIRTUAL SCHEMA` usage, refresh workflows, and query-side troubleshooting.
日本語の概要は準備中です。原文の説明を表示しています。
Use Exasol `EXPORT` and `EXPORT INTO` SQL plus `exapump export` local file workflows for moving data out of Exasol. Covers native CSV/FBV export, local CSV/Parquet exports with exapump, `CREATE CONNECTION` connection objects for export, FTP, SFTP, HTTP, HTTPS, and cloud targets on S3, Azure Blob Storage, and Google Cloud Storage (GCS), reject limits, and export credential patterns.
日本語の概要は準備中です。原文の説明を表示しています。