scriptoriumadmin/featurebase
1
0
Fork 0
mirror of https://github.com/featurebasedb/featurebase.git synced 2026-08-28 10:54:59 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
featurebase/server_test.go
Seebs 54dbeec1af support null/non-null tests for non-BSI fields 
There's a lot going on here. First, we were treating "the test is
a Condition" as implying BSI, which it doesn't anymore. Second, the
behavior of conditions was weird and BSI-specific. Third, we had
to propagate these changes and features throughout a bunch of code,
including both the core featurebase code and the DAX replacements/copies
of it, plus the SQL3 layer.

We refactor this so that tests for equality and inequality work for
non-BSI fields, so now if you accidentally use `==` in a Row call
on a non-BSI field, it still works; that's not specific to BSI
fields anymore.

We add a TrackExistence flag to fields, and propagate it through
things like our protobuf code, etcetera, so that we can successfully
create fields. Newly-created fields get this by default, because
we add it unconditionally to them, but the paths that are being
called with existing fields don't add it. So, when we "create"
(really, just load the definition of) a field from something stored
in the schema, we don't add TrackExistence to it, but any path to
creating a new field should.

A time quantum field with NoStandardView will *effectively*
lack TrackExistence.

For sets, mutexes, and time quantums with a standard view, anything
that sets bits will also set a corresponding bit for the record in
a new "existence" view. This allows us to distinguish between an
empty set and a null, and also allows null checks to be constant-time.

When clearing bits, we don't clear existence bits EXCEPT that if
you clear a bit in a mutex, *and the bit actually existed*, we clear
the existence bit. For sets and time quantums, clearing bits never
clears the existence bit.

Deleting records clears the existence bit.

We also add code to the `batch` subpackage to generate suitable
existence field bitmaps and import them. This logic correctly handles
empty sets and nils. The `batch` package does not allow specification
of anything equivalent to clearing a single bit from an existing
record, so we don't have to deal with the mutex complexity in that
case, which is good because it would be impossible.

This requires a number of other subtle changes, such as allowing
new fields to have more than one FieldOption specified for them.

We also drop the handful of implementation bits relating to the
"fullySorted" internal-use-only import flag, which existed only to
support the JSON ingest API, which we've removed.

The most dangerous part of this is that the mutex semantics are
impossible to implement on top of our existing API, because they
require us to know, not how *many* bits we cleared, but which
*specific* bits we cleared. I've implemented this as a new Tx method,
which is almost certainly going to be tech debt one day; if we some
day drop the Import API, we should remove that.

The testing for this is only currently covering the Set/Clear
behavior of PQL, and the Import API. The batch tests haven't been
written yet.

Fields that don't have existence tracking enabled refuse to perform
null/not-null tests. They should also report themselves as having
no null values -- if a record exists, sets in it are considered
empty rather than null.

The SQL3 support requires a number of subtle modifications to both
featurebase and some addon tooling. The essential thing is dropping
the unconditional translation of nil slices to non-nil empty slices
in translateResult, both in the executor and the orchestrator. We
also modify the logic that handles generating results from Extract
calls, to ensure that non-null sets get an empty slice created for
them even if they never have any values assigned.

The expected results for some tests are different now; we expect to
get nil slices, rather than 0-length non-nil slices, for fields which
were never written for a given record. Most tests were not changed.
(In every case, if a test was failing, I actually checked the logic
before changing expected results. This required a lot of tracking down
of edge cases.)

The batch package now rejects as an error attempts to clear single
bits from mutex fields, because so far as I can tell it's simply
impossible to have a roaring import that specifies the correct semantics
there; you can't tell whether to clear an existence bit without
access to the currently-set bits, which the batch API doesn't have.
We already supported the special case of specifying a clear value
of nil for clearing a mutex field; now that is the only allowed
value for a mutex field to have in row.Clears.

We change the logic for fixing up incoming view names (in two places)
to stop assuming that any view in a time field other than "" that does
not have viewStandard as a prefix is a partial time quantum name that
should have "standard_" prepended to it. This allows us to submit
bitmaps for "existence" to time quantum fields and not have them
silently transformed into "standard_existence" because that's what we'd
do with "202203".

We drop the field ClearBits method, which was totally unused.

We drop the sliceDifference function, which was used in a previous
mutex implementation and hasn't been used in ages, and the test
case for it, and the helper function used only by that test case.
2023-03-24 16:01:09 -05:00

285 lines
11 KiB
Go
Raw Blame History

// Copyright 2022 Molecula Corp. (DBA FeatureBase).
// SPDX-License-Identifier: Apache-2.0
package pilosa_test
import (
"context"
"fmt"
"reflect"
"sort"
"testing"
"time"
pilosa "github.com/featurebasedb/featurebase/v3"
"github.com/featurebasedb/featurebase/v3/test"
)
func TestViewsRemovalTTL(t *testing.T) {
cluster := test.MustRunCluster(t, 1)
node := cluster.GetNode(0)
defer cluster.Close()
// Create a client
client := node.Client()
indexName := cluster.Idx()
// Create indexes and field with ttl lasting 24 hours
if err := client.CreateIndex(context.Background(), indexName, pilosa.IndexOptions{TrackExistence: true}); err != nil && err != pilosa.ErrIndexExists {
t.Fatalf("creating index, err: %v", err)
}
dateNow := time.Now().UTC()
dateYesterday := dateNow.Add(-24 * time.Hour)
dateCurrentMonth := time.Date(dateNow.Year(), dateNow.Month(), 1, 0, 0, 0, 0, time.UTC)
dateLastDayOfMonth := dateCurrentMonth.AddDate(0, 1, 0).Add(-time.Nanosecond)
var tests = []struct {
name string
date string
expViews []string
}{
{
name: "date_old",
date: "2001-02-03T04:05",
expViews: []string{"existence", "standard"},
/* date_old (2001-02-03T04:05), this will create these views:
- standard
- standard_2001
- standard_200102
- standard_20010203
- standard_2001020304
Since the sample date here is over 20 years all views except "standard" should get deleted
*/
},
{
name: "date_now",
date: fmt.Sprintf("%d-%02d-%02dT%02d:%02d", dateNow.Year(), dateNow.Month(), dateNow.Day(), dateNow.Hour(), dateNow.Minute()),
expViews: []string{
"existence",
"standard",
"standard_" + fmt.Sprintf("%d", dateNow.Year()),
"standard_" + fmt.Sprintf("%d%02d", dateNow.Year(), dateNow.Month()),
"standard_" + fmt.Sprintf("%d%02d%02d", dateNow.Year(), dateNow.Month(), dateNow.Day()),
"standard_" + fmt.Sprintf("%d%02d%02d%02d", dateNow.Year(), dateNow.Month(), dateNow.Day(), dateNow.Hour()),
},
/* For example: current time is 2022-05-11T15:17 (also when the 24 hrs ttl countdown starts) will generate these views:
- standard_2022 -> end date is 2023_01_01 T00:00, in future -> keep
- standard_202205 -> end date is 2022_06_01 T00:00, in future -> keep
- standard_20220511 -> end date is 2022_05_12 T00:00, in future -> keep
- standard_2022051115 -> end date is 2022_05_11 T18:00, in future -> keep
*/
},
{
name: "date_yesterday",
date: fmt.Sprintf("%d-%02d-%02dT%02d:%02d", dateYesterday.Year(), dateYesterday.Month(), dateYesterday.Day(), dateYesterday.Hour(), dateYesterday.Minute()),
expViews: []string{
"existence",
"standard",
"standard_" + fmt.Sprintf("%d", dateYesterday.Year()),
"standard_" + fmt.Sprintf("%d%02d", dateYesterday.Year(), dateYesterday.Month()),
"standard_" + fmt.Sprintf("%d%02d%02d", dateYesterday.Year(), dateYesterday.Month(), dateYesterday.Day()),
"standard_" + fmt.Sprintf("%d%02d%02d%02d", dateYesterday.Year(), dateYesterday.Month(), dateYesterday.Day(), dateYesterday.Hour()),
},
/* Example: current time is 2022-05-11T15:17, date_yesterday (2022-05-10T15:17) will generate these views:
- standard_2022 -> end date is 2023_01_01 T00:00, in future -> keep
- standard_202205 -> end date is 2022_06_01 T00:00, in future -> keep
- standard_20220510 -> end date is 2022_05_11 T00:00, within 24 hrs -> keep
- standard_2022051015 -> end date is 2022_05_10 T16:00, within 24 hrs -> keep
*/
},
// {
// name: "date_first_of_month",
// date: fmt.Sprintf("%d-%02d-%02dT%02d:%02d", dateCurrentMonth.Year(), dateCurrentMonth.Month(), 1, 0, 0),
// expViews: []string{
// "standard",
// "standard_" + fmt.Sprintf("%d", dateCurrentMonth.Year()),
// "standard_" + fmt.Sprintf("%d%02d", dateCurrentMonth.Year(), dateCurrentMonth.Month()),
// },
// /* Example: current time is 2022-05-11T15:17, date_first_of_month (2022-05-01T00:00) will generate these views:
// - standard_2022 -> end date is 2023_01_01 T00:00, in future -> keep
// - standard_202205 -> end date is 2022_06_01 T00:00, in future -> keep
// - standard_20220501 -> end date is 2022_05_02 T00:00, older than ttl -> delete
// - standard_2022050115 -> end date is 2022_05_01 T01:00, older than ttl -> delete
// !!! commenting this test out for now, there is a special case where if today's date is also same as date_first_of_month
// in that case, the expected views would have all 4, instead of 2 in the above example, since they are not older than the 24 hr ttl
// */
// },
{
name: "date_last_of_month",
date: fmt.Sprintf("%d-%02d-%02dT%02d:%02d", dateLastDayOfMonth.Year(), dateLastDayOfMonth.Month(), dateLastDayOfMonth.Day(), dateLastDayOfMonth.Hour(), dateLastDayOfMonth.Minute()),
expViews: []string{
"existence",
"standard",
"standard_" + fmt.Sprintf("%d", dateLastDayOfMonth.Year()),
"standard_" + fmt.Sprintf("%d%02d", dateLastDayOfMonth.Year(), dateLastDayOfMonth.Month()),
"standard_" + fmt.Sprintf("%d%02d%02d", dateNow.Year(), dateNow.Month(), dateLastDayOfMonth.Day()),
"standard_" + fmt.Sprintf("%d%02d%02d%02d", dateNow.Year(), dateNow.Month(), dateLastDayOfMonth.Day(), dateLastDayOfMonth.Hour()),
},
/* Example: current time is 2022-05-11T15:17, date_last_of_month (2022-05-31T23:59) will generate these views:
- standard_2022 -> end date is 2023_01_01 T00:00, in future -> keep
- standard_202205 -> end date is 2022_06_01 T00:00, in future -> keep
- standard_20220531 -> end date is 2022_06_01 T00:00, in future -> keep
- standard_2022053123 -> end date is 2022_06_01 T00:00, in future -> keep
*/
},
{
name: "date_first_hour_day",
date: fmt.Sprintf("%d-%02d-%02dT%02d:%02d", dateNow.Year(), dateNow.Month(), dateNow.Day(), 0, 0),
expViews: []string{
"existence",
"standard",
"standard_" + fmt.Sprintf("%d", dateNow.Year()),
"standard_" + fmt.Sprintf("%d%02d", dateNow.Year(), dateNow.Month()),
"standard_" + fmt.Sprintf("%d%02d%02d", dateNow.Year(), dateNow.Month(), dateNow.Day()),
"standard_" + fmt.Sprintf("%d%02d%02d%02d", dateNow.Year(), dateNow.Month(), dateNow.Day(), 0),
},
/* Example: current time is 2022-05-11T15:17, date_first_hour_day (2022-05-11T00:00) will generate these views:
- standard_2022 -> end date is 2023_01_01 T00:00, in future -> keep
- standard_202205 -> end date is 2022_06_01 T00:00, in future -> keep
- standard_20220511 -> end date is 2022_05_12 T00:00, in future -> keep
- standard_2022051100 -> end date is 2022_05_01 T01:00, within TTL -> keep
*/
},
{
name: "date_last_hour_day",
date: fmt.Sprintf("%d-%02d-%02dT%02d:%02d", dateNow.Year(), dateNow.Month(), dateNow.Day(), 23, 59),
expViews: []string{
"existence",
"standard",
"standard_" + fmt.Sprintf("%d", dateNow.Year()),
"standard_" + fmt.Sprintf("%d%02d", dateNow.Year(), dateNow.Month()),
"standard_" + fmt.Sprintf("%d%02d%02d", dateNow.Year(), dateNow.Month(), dateNow.Day()),
"standard_" + fmt.Sprintf("%d%02d%02d%02d", dateNow.Year(), dateNow.Month(), dateNow.Day(), 23),
},
/* Example: current time is 2022-05-11T15:17, date_last_hour_day (2022-05-11T23:59) will generate these views:
- standard_2022 -> end date is 2023_01_01 T00:00, in future -> keep
- standard_202205 -> end date is 2022_06_01 T00:00, in future -> keep
- standard_20220511 -> end date is 2022_05_12 T00:00, in future -> keep
- standard_2022051123 -> end date is 2022_05_12 T00:00, in future -> keep
*/
},
}
for _, test := range tests {
t.Run(test.name, func(t *testing.T) {
if err := client.CreateFieldWithOptions(context.Background(), indexName, test.name, pilosa.FieldOptions{TTL: time.Hour * 24, Type: pilosa.FieldTypeTime, TimeQuantum: "YMDH"}); err != nil {
t.Fatalf("creating field, err: %v", err)
}
// set data
_, err := client.Query(context.Background(), indexName, &pilosa.QueryRequest{Index: indexName, Query: "Set(1, " + test.name + "=1, " + test.date + ")"})
if err != nil {
t.Fatalf("setting sample data, err: %v", err)
}
// run ViewsRemoval
node.Server.ViewsRemoval(context.Background())
// Get all the views for given index + field
views, err := node.API.Views(context.Background(), indexName, test.name)
if err != nil {
t.Fatal(err)
}
var viewNames []string
for _, view := range views {
viewNames = append(viewNames, view.Name())
}
sort.Strings(viewNames)
if !reflect.DeepEqual(test.expViews, viewNames) {
t.Fatalf("after ttl removal, expected %v, but got %v", test.expViews, viewNames)
}
})
}
}
func TestViewsRemovalStandard(t *testing.T) {
cluster := test.MustRunCluster(t, 1)
node := cluster.GetNode(0)
defer cluster.Close()
// Create a client
client := node.Client()
indexName := cluster.Idx()
// Create indexes and field with ttl lasting 24 hours
if err := client.CreateIndex(context.Background(), indexName, pilosa.IndexOptions{TrackExistence: true}); err != nil && err != pilosa.ErrIndexExists {
t.Fatalf("creating index, err: %v", err)
}
var tests = []struct {
name string
date string
noStandardView string
expViews []string
}{
{
name: "t1_delete_standard",
date: "2001-02-03T04:05",
noStandardView: "true",
expViews: nil,
/* date 2001-02-03T04:05, this will create these views:
- standard
- standard_2001
- standard_200102
- standard_20010203
- standard_2001020304
Since the sample date here is over 20 years, all views with dates should get deleted
Since noStandardView is true, 'standard' view should get deleted
*/
},
{
name: "t2_keep_standard",
date: "2001-02-03T04:05",
noStandardView: "false",
expViews: []string{"existence", "standard"},
/* date 2001-02-03T04:05, this will create these views:
- standard
- standard_2001
- standard_200102
- standard_20010203
- standard_2001020304
Since the sample date here is over 20 years, all views with dates should get deleted
Since noStandardView is false, 'standard' view should NOT get deleted
*/
},
}
for _, test := range tests {
t.Run(test.name, func(t *testing.T) {
if err := client.CreateFieldWithOptions(context.Background(), indexName, test.name, pilosa.FieldOptions{TTL: time.Hour * 24, Type: pilosa.FieldTypeTime, TimeQuantum: "YMDH"}); err != nil {
t.Fatalf("creating field, err: %v", err)
}
// set data
_, err := client.Query(context.Background(), indexName, &pilosa.QueryRequest{Index: indexName, Query: "Set(1, " + test.name + "=1, " + test.date + ")"})
if err != nil {
t.Fatalf("setting sample data, err: %v", err)
}
// update noStandardView value
err = node.API.UpdateField(context.Background(), indexName, test.name, pilosa.FieldUpdate{Option: "noStandardView", Value: test.noStandardView})
if err != nil {
t.Fatalf("updating noStandardView, err: %v", err)
}
// run ViewsRemoval
node.Server.ViewsRemoval(context.Background())
// get all the views for given index + field
views, err := node.API.Views(context.Background(), indexName, test.name)
if err != nil {
t.Fatal(err)
}
var viewNames []string
for _, view := range views {
viewNames = append(viewNames, view.Name())
}
sort.Strings(viewNames)
if !reflect.DeepEqual(test.expViews, viewNames) {
t.Fatalf("after ttl removal, expected %v, but got %v", test.expViews, viewNames)
}
})
}
}
Reference in a new issue View git blame Copy permalink