Mutations
Olytix Core's GraphQL API provides mutation operations for managing caches, pre-aggregations, and project state.
Cache Management
Invalidate Cube Cache
Invalidate all cached query results for a specific cube. Use this after data updates to ensure fresh results.
mutation {
invalidateCache(cube: "orders")
}
Response:
{
"data": {
"invalidateCache": true
}
}
Use Cases:
- After loading new data into the warehouse
- When cube definitions have changed
- To force recalculation of cached aggregations
Example with Variables:
mutation InvalidateOrdersCache($cubeName: String!) {
invalidateCache(cube: $cubeName)
}
Variables:
{
"cubeName": "orders"
}
Pre-aggregation Management
Refresh Pre-aggregation
Trigger an immediate refresh of a pre-aggregation table. This is useful when you need fresh aggregated data outside the normal refresh schedule.
mutation {
refreshPreAggregation(
cube: "orders"
preAggregation: "orders_by_region_daily"
) {
success
message
jobId
}
}
Response:
{
"data": {
"refreshPreAggregation": {
"success": true,
"message": "Pre-aggregation refresh triggered successfully",
"jobId": "preagg_refresh_abc123"
}
}
}
Use Cases:
- After significant data loads
- When data corrections have been applied
- Before generating critical reports
Error Response:
{
"data": {
"refreshPreAggregation": {
"success": false,
"message": "Pre-aggregation 'invalid_preagg' not found in cube 'orders'",
"jobId": null
}
}
}
Refresh Multiple Pre-aggregations
Use aliases to refresh multiple pre-aggregations in a single request.
mutation RefreshAllOrdersPreaggs {
daily: refreshPreAggregation(
cube: "orders"
preAggregation: "orders_by_region_daily"
) {
success
jobId
}
weekly: refreshPreAggregation(
cube: "orders"
preAggregation: "orders_by_region_weekly"
) {
success
jobId
}
monthly: refreshPreAggregation(
cube: "orders"
preAggregation: "orders_by_region_monthly"
) {
success
jobId
}
}
Response:
{
"data": {
"daily": {
"success": true,
"jobId": "preagg_refresh_abc123"
},
"weekly": {
"success": true,
"jobId": "preagg_refresh_def456"
},
"monthly": {
"success": true,
"jobId": "preagg_refresh_ghi789"
}
}
}
Subscriptions
Olytix Core also provides real-time subscriptions for monitoring long-running operations.
Subscribe to Query Updates
Monitor updates for a long-running or periodic query.
subscription {
queryUpdates(queryId: "query_abc123") {
data
meta {
executionTimeMs
fromCache
}
}
}
Subscribe to Pre-aggregation Status
Monitor the build status of pre-aggregations for a cube.
subscription {
preAggregationStatus(cube: "orders") {
name
status
lastRefreshAt
nextRefreshAt
rowCount
sizeBytes
}
}
Status Values:
| Status | Description |
|---|---|
NOT_BUILT | Pre-aggregation has never been built |
BUILDING | Build is currently in progress |
FRESH | Pre-aggregation is up to date |
STALE | Pre-aggregation needs refresh |
FAILED | Last build attempt failed |
Example Output:
{
"data": {
"preAggregationStatus": {
"name": "orders_by_region_daily",
"status": "BUILDING",
"lastRefreshAt": "2024-01-20T08:00:00Z",
"nextRefreshAt": "2024-01-21T08:00:00Z",
"rowCount": null,
"sizeBytes": null
}
}
}
Combining Mutations with Queries
You can combine mutations with queries in a single request to perform an action and retrieve updated state.
mutation InvalidateAndVerify {
invalidateCache(cube: "orders")
}
query VerifyCacheStatus {
cube(name: "orders") {
name
measures {
name
}
}
}
Error Handling
Mutation errors follow standard GraphQL error conventions:
{
"data": {
"refreshPreAggregation": null
},
"errors": [
{
"message": "Pre-aggregation service not available",
"locations": [{ "line": 2, "column": 3 }],
"path": ["refreshPreAggregation"],
"extensions": {
"code": "SERVICE_UNAVAILABLE"
}
}
]
}
Common Error Codes
| Code | Description |
|---|---|
CUBE_NOT_FOUND | The specified cube does not exist |
PREAGG_NOT_FOUND | The specified pre-aggregation does not exist |
SERVICE_UNAVAILABLE | Required service is not available |
PERMISSION_DENIED | User lacks permission for this operation |
RATE_LIMITED | Too many requests, try again later |
Best Practices
Cache Invalidation
- Be specific: Invalidate only the cubes that have changed data
- Schedule during low traffic: Run cache invalidations during off-peak hours when possible
- Monitor after invalidation: Expect slightly higher query latency immediately after cache invalidation
Pre-aggregation Refresh
- Track job IDs: Store returned job IDs to monitor refresh progress via subscriptions
- Avoid overlapping refreshes: Check if a refresh is already in progress before triggering another
- Handle failures gracefully: Implement retry logic for failed refreshes
# Check status before triggering refresh
query CheckStatus {
cube(name: "orders") {
name
}
}
# Then trigger refresh if needed
mutation ConditionalRefresh {
refreshPreAggregation(
cube: "orders"
preAggregation: "orders_by_region_daily"
) {
success
jobId
message
}
}