Michael Gaffney
47ddd2e40a
The hcp billing `_all` views built a range of buckets using the
`generate_series` function using the minimum value of the
`session_pending_time` column from the `wh_session_accumulating_fact`
table as the start time and `now()` as the end time. It then truncated
values in the series using the `date_trunc` function. This allowed the
generated series of buckets returned to vary and could result in one
additional bucket being included in the series depending on the current
time and the start time.
As an illustrative example, the `hourly_all` query used:
select date_trunc('hour',time)
from generate_series(
(select min(session_pending_time) -- start time
from wh_session_accumulating_fact),
now(),
'1 hour'::interval
) as time;
Substituting the start time with a hard coded value to show the issue:
-- Show current time, where the minutes portion is 55
select now();
now
-------------------------------
2023-05-22 14:55:40.567605+00
(1 row)
-- generate series with start time's minutes portion at 57
select date_trunc('hour',time)
from generate_series(
'2023-05-22 01:57:00'::timestamptz,
now(),
'1 hour'::interval
) as time;
date_trunc
------------------------
2023-05-22 01:00:00+00
2023-05-22 02:00:00+00
2023-05-22 03:00:00+00
2023-05-22 04:00:00+00
2023-05-22 05:00:00+00
2023-05-22 06:00:00+00
2023-05-22 07:00:00+00
2023-05-22 08:00:00+00
2023-05-22 09:00:00+00
2023-05-22 10:00:00+00
2023-05-22 11:00:00+00
2023-05-22 12:00:00+00
2023-05-22 13:00:00+00
(13 rows)
-- Wait a few minutes
select now();
now
------------------------------
2023-05-22 14:58:48.75287+00
(1 row)
-- Now run again and get an extra result, even though still
-- within the same hour
select date_trunc('hour',time)
from generate_series(
'2023-05-22 01:57:00'::timestamptz,
now(),
'1 hour'::interval
) as time;
date_trunc
------------------------
2023-05-22 01:00:00+00
2023-05-22 02:00:00+00
2023-05-22 03:00:00+00
2023-05-22 04:00:00+00
2023-05-22 05:00:00+00
2023-05-22 06:00:00+00
2023-05-22 07:00:00+00
2023-05-22 08:00:00+00
2023-05-22 09:00:00+00
2023-05-22 10:00:00+00
2023-05-22 11:00:00+00
2023-05-22 12:00:00+00
2023-05-22 13:00:00+00
2023-05-22 14:00:00+00
(14 rows)
To fix this, we call the `generate_series` function truncating the start
time argument to the bucket size:
-- Hourly
select bucket
from generate_series(
date_trunc('hour', select min(session_pending_time)
from wh_session_accumulating_fact)),
now(),
'1 hour'::interval
) as bucket;
-- Monthly
select bucket
from generate_series(
date_trunc('month', select min(session_pending_time)
from wh_session_accumulating_fact)),
now(),
'1 month'::interval
) as bucket;
Fixes: 41b1b5b4b7
db package
Usage
Just some high-level usage highlights to get you started. Read the godocs for a complete list of capabilities and their documentation.
dialect = postgres.New(postgres.Config{
DSN: connectionUrl},
)
conn, _ := gorm.Open(dialect, &gorm.Config{})
// Db implements both the Reader and Writer interfaces
rw := Db{Tx: conn}
// There are writer methods like: Create, Update and Delete
// that will write Gorm struct to the db. These writer methods
// all support options for writing Oplog entries for the
// caller: WithOplog(yourWrapper, yourMetadata)
// the caller is responsible for the transaction life cycle of the writer
// and if an error is returned the caller must decide what to do with
// the transaction, which is almost always a rollback for the caller.
err = rw.Create(context.Background(), user)
// There are reader methods like: LookupByPublicId,
// LookupByName, SearchBy, LookupBy, etc
// which will lookup resources for you and scan them into your Gorm struct
err = rw.LookupByPublicId(context.Background(), foundUser)
// There's reader ScanRows that facilitates scanning rows from
// a query into your Gorm struct
where := "select * from test_users where name in ($1, $2)"
rows, err := rw.Query(context.Background(), where, []interface{}{"alice", "bob"})
defer rows.Close()
for rows.Next() {
user := db_test.NewTestUser()
// scan the row into your Gorm struct
if err := rw.ScanRows(rows, &user); err != nil {
return err
}
// Do something with the Gorm user struct
}
// DoTx is a writer function that wraps a TxHandler
// in a retryable transaction. You simply implement a
// TxHandler that does your writes and hand the handler
// to DoTx, which will wrap the writes in a retryable
// transaction with the retry attempts and backoff
// strategy you specify via options.
_, err = w.DoTx(
context.Background(),
10, // ten retries
ExpBackoff{}, // exponential backoff
func(w Writer) error {
// the TxHandler updates the user's friendly name
return w.Update(context.Background(), user, []string{"FriendlyName"},
// write oplogs for this update
WithOplog(
InitTestWrapper(t),
oplog.Metadata{
"key-only": nil,
"deployment": []string{"amex"},
"project": []string{"central-info-systems", "local-info-systems"},
},
),
)
})