Built for Every Sector
How FlinDB Helps
Undo/Redo
Built into the database, not your application code
The Problem
Implementing undo/redo in traditional applications requires maintaining command stacks, managing state snapshots, and writing complex logic to reverse operations. This adds significant development time and bugs.
The FlinDB Solution
Since every entity automatically maintains its version history, undo is
simply accessing the previous version: entity@-1. No command
patterns, no state management libraries, no complex logic.
- One-line undo implementation
- Unlimited undo depth (all versions saved)
- Works automatically with no extra code
- Can undo specific fields or entire entities
// One-line undo
undo = fn() {
todo = todo@-1 // Previous version
save todo
}
// Bulk undo
undo_all = fn() {
todos = todos.map(t => t@-1)
save todos
}
// Undo to specific point
restore_from = fn(date) {
todo = todo@date
save todo
}Audit Trails
Automatic, always-on, zero code required
The Problem
Building audit trails traditionally requires: creating audit tables, adding triggers or interceptors, tracking who changed what when, and building UIs to display this history. It's a major undertaking.
The FlinDB Solution
Every entity change is automatically versioned with timestamps.
Use entity.history() to get the complete audit trail.
No triggers, no extra tables, no configuration.
- Every change tracked automatically
- Timestamps on all versions
- Compare any two versions instantly
- Built-in, always enabled
// Get full history
versions = user.history()
// Display audit trail
{for v in versions}
<div>
Version {v.version}
Changed: {v.updated_at}
Name: {v.name}
</div>
{/for}
// Compare versions
old = user@-1
if user.email != old.email {
log("Email changed")
}Compliance
GDPR, HIPAA, SOX - full data history built-in
The Problem
Compliance regulations require maintaining complete records of data changes, being able to prove what data existed at any point in time, and providing "right to be forgotten" capabilities.
The FlinDB Solution
Time-travel queries let you prove exactly what data existed at any
moment. The CRUDD model with delete (soft) vs
destroy (hard) gives you both audit trails and true
GDPR-compliant data erasure.
- Prove data state at any point in time
- Soft delete for recoverable audit trails
- Hard destroy for GDPR "right to be forgotten"
- Complete version history for compliance audits
// Prove state at audit date
audit_date = "2024-03-15"
records = Patient.all@audit_date
// CRUDD: Soft delete (audit trail)
delete user // Recoverable
restore user // Can undo
// CRUDD: Hard delete (GDPR)
destroy user // Permanent
// No history, truly forgottenDebugging
"What did this look like yesterday?"
The Problem
Debugging data issues often involves trying to reconstruct what the data looked like when a bug occurred. Without version history, this is nearly impossible and relies on logs if you're lucky.
The FlinDB Solution
Simply query the entity at the point in time when the bug occurred.
user@"2024-01-15 14:30" shows you exactly what that
record looked like. Database archaeology is over.
- See exact state at any timestamp
- Compare before/after bug introduction
- No log parsing or guesswork
- Pinpoint when data changed
// Bug reported at 2:30 PM
bug_time = "2024-01-15 14:30"
// What did user look like then?
user_then = user@bug_time
// Compare with current
log("Then: {user_then.email}")
log("Now: {user.email}")
// Find when value changed
history = user.history()
{for v in history}
if v.email != "expected" {
log("Changed at {v.updated_at}")
}
{/for}Data Recovery
Restore any entity from any point in time
The Problem
Accidental deletions or corrupted data typically require restoring from backups - if they exist and are recent enough. This process is slow, error-prone, and often incomplete.
The FlinDB Solution
Every version is preserved. Recovering data is as simple as querying the entity at a past date and saving it. Soft-deleted entities can be restored with a single command.
- Recover any entity to any previous state
- Restore soft-deleted records instantly
- No backup tapes or restore procedures
- Point-in-time recovery always available
// Accidentally deleted?
restore user // Soft delete undo
// Restore to previous state
user = user@-1
save user
// Restore from specific date
recover = fn(id, date) {
entity = Entity.find(id)@date
save entity
return entity
}
recovered = recover(42, "2024-01-10")A/B Testing & Analytics
Compare states across time periods
The Problem
Measuring the impact of changes requires comparing metrics before and after. This typically involves pre-planning analytics events, storing snapshots, and building complex comparison dashboards.
The FlinDB Solution
Query metrics at any two points in time and compare directly.
Metrics.all@before vs Metrics.all@after
gives you instant before/after analysis without any prior setup.
- Compare any time periods instantly
- No pre-planned analytics events needed
- Retrospective analysis always possible
- Calculate deltas between any versions
// A/B test analysis
launch_date = "2024-06-15"
// Get metrics before and after
before = Metrics.all@(launch_date - 7.days)
after = Metrics.all
// Compare
comparison = {
before_avg: average(
before.map(m => m.conversion)
),
after_avg: average(
after.map(m => m.conversion)
)
}
improvement = comparison.after_avg -
comparison.before_avg