Lars wrote: <<<Flashback queries only makes sense with TTL>>>. This is not true. A simple CF with VERSIONS=1 & no TTL (i.e. TTL of infinity) can also benefit from ability to FlashBack query. Flash back is simply an ability to query the DB as of a previous point in time. Why should we overload that functionality with versions, TTL, etc.?
I think it is useful to think of FlashBack as completely independent of other settings like TTL, MAXVERSIONS, MINVERSIONS, etc. The latter should be picked at schema design time based on the application requirements. For example, you may have many tables in your system with different TTL, VERSIONS requirements. Maybe you have different CFs within a table, with differing TTL & VERSION requirements.
But on top of all those, suppose across all my tables I want to be able to query the entire DB as of a previous point in time. From a user's point of view, the only setting they need to worry about is the "time period" (back in time) up to which flash back queries are supported.
For example, you might have one CF, with VERSIONS=1, where you are keeping hourly rollup data that you want to retain for 1 month (TTL) and, another CF where you keep daily rollup data also with VERSIONS=1 where you want to retain data for 3 years. But separately, I want the ability to be able to do flash back queries up to say 7 days back. This "7 days" should be a completely different setting, and there seems to be no reason to confuse this with TTL & Verions.
Now, API wise, we need the ability to say that we are doing a flashback query i.e. "Scan @ T" instead of regular "Scan". In Oracle DB too, for instance, flash back queries have this special syntax:
SELECT * FROM employee
AS OF TIMESTAMP <TS>
WHERE name = 'JOHN';
Regarding <<< So the snapshot scanner is special in that only through this specific scanner you can look further back than the TTL.>>>: I think that is by design. Note: Scan @ T (flash back query) is different than doing a Scan with setTimeRange(0, T). A delete done a T+1 of a key is immaterial for Scan @ T query; whereas for a Scan with setTimeRange(0, T), you will still see the effect of the delete done at T+1.
In summary, we should not confuse our users by forcing them to change their schema design (i.e. choice of VERSIONS, TTL, etc.) to support flashback queries. Flashback support should be configured using a simple extra knob that can be set a system, table or CF level. We should NOT overload that knob with TTL and Versions.