Data Operations in Practice — CRUD, Filtering, and Aggregation
This page is mainly for Skill authors, delivery teams, and Agent maintainers. Business users generally just describe "what I want to query or change" — the actual data commands are usually executed by the Agent in the background.
What the data commands do
data is the most-used command family in the Lovrabet Runtime CLI, split into two categories:
- Read: list records, fetch a single record, compute statistics
- Write: create, correct, delete
The commands are:
data filterdata getOnedata aggregatedata createdata batchCreatedata updatedata delete
What all data commands share
They all revolve around two parameters:
--code: the dataset code, required--params: a JSON parameter that drives filters, pagination, write payloads, and so on
In other words, the Agent typically knows (or first discovers) a dataset code, then executes the actual read or write with --params.
Read operations: list, single record, statistics
1. data filter
Good for:
- Fetching a batch of records
- Conditional filtering
- Pulling detail lists
lovrabet data filter --code <datasetCode> --params '{"where":{"status":{"$eq":"active"}},"currentPage":1,"pageSize":20}'Typical scenarios:
- Unshipped orders from the last 7 days
- Customers added in the last 30 days with no first order yet
- All tickets in a given status
2. data getOne
Good for:
- Fetching one record by
idor a single primary key - Checking what state a specific record is actually in
lovrabet data getOne --code <datasetCode> --params '{"id":123}'3. data aggregate
Good for:
- Summarizing by dimension
- Producing operational stats, reconciliation figures, or management dashboard inputs
lovrabet data aggregate --code <datasetCode> --params '{
"aggregate":[{"field":"amount","type":"SUM","alias":"total"}],
"groupBy":["status"]
}'Write operations: create, correct, delete
1. data create
Creates a new record:
lovrabet data create --code <datasetCode> --params '{"name":"test"}'2. data batchCreate
Creates multiple records at once:
lovrabet data batchCreate --code <datasetCode> --params '[{"name":"a"},{"name":"b"}]'3. data update
Modifies an existing record:
lovrabet data update --code <datasetCode> --params '{"id":123,"status":"completed"}'4. data delete
Deletes records:
lovrabet data delete --code <datasetCode> --params '{"id":123}' --yesBefore any write, remember two things
First: run --dry-run
Preview write commands first:
lovrabet data update --code <datasetCode> --params '{"id":123,"status":"completed"}' --dry-run--dry-run shows you how the API would be called and with what parameters — without executing anything.
Second: check the risk level
create/batchCreate/updatearewritedeleteishigh-risk-write
If the current riskLevel isn't sufficient, the CLI blocks the command. For high-risk deletes in non-interactive mode, --yes is also mandatory.
Common filter syntax
data filter most commonly uses where conditions:
| Operator | Meaning |
|---|---|
$eq | equals |
$ne | not equals |
$gt / $gte | greater than / greater than or equal |
$lt / $lte | less than / less than or equal |
$in | in a set |
$contain | contains a substring |
$startWith / $endWith | starts with / ends with |
$and / $or | combine conditions |
For example:
lovrabet data filter --code <datasetCode> --params '{
"where":{
"$and":[
{"amount":{"$gte":100}},
{"status":{"$eq":"active"}}
]
}
}'The most common aggregation types
| Type | Meaning |
|---|---|
SUM | sum |
COUNT | count |
AVG | average |
MAX / MIN | maximum / minimum |
How business users should phrase requests
Instead of saying:
Run
data aggregatefor me
Say directly:
Summarize the unshipped order count for the last 7 days by warehouse
Or:
Change requirement 241 to "processing" — preview first, then execute
This lets the Agent decide naturally whether to use filter, aggregate, update, or start with dataset discovery.
One-sentence summary
The data commands carry the actual business actions:
- List records →
filter - Fetch one record →
getOne - Compute summaries →
aggregate - Create / correct →
create/batchCreate/update - Delete →
delete
For business users, the point isn't memorizing these names — it's stating the business object, the conditions, the expected result, and the risk boundary clearly.