rocksdb #29
25
db/db.go
|
|
@ -1,11 +1,13 @@
|
|||
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
package db
|
||||
|
||||
// db.go contains basic functions for representing and accessing the state of
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
// a read-only version of the rocksdb database.
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
import (
|
||||
"bytes"
|
||||
"encoding/hex"
|
||||
"fmt"
|
||||
"os"
|
||||
"sort"
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
"time"
|
||||
|
||||
"github.com/lbryio/hub/db/db_stack"
|
||||
|
|
@ -305,13 +307,6 @@ func (ps *PathSegment) String() string {
|
|||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
return ps.name
|
||||
}
|
||||
|
||||
// BisectRight returns the index of the first element in the list that is greater than or equal to the value.
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
// https://stackoverflow.com/questions/29959506/is-there-a-go-analog-of-pythons-bisect-module
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
func BisectRight(arr []interface{}, val uint32) uint32 {
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
i := sort.Search(len(arr), func(i int) bool { return arr[i].(uint32) >= val })
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
return uint32(i)
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
}
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
//
|
||||
// Iterators / db construction functions
|
||||
//
|
||||
|
|
@ -539,6 +534,11 @@ func GetDBColumnFamlies(name string, secondayPath string, cfNames []string) (*Re
|
|||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
|
||||
// Advance advance the db to the given height.
|
||||
func (db *ReadOnlyDBColumnFamily) Advance(height uint32) {
|
||||
|
needs doing? needs doing?
No, this is an extra check that was in the python that isn't actually needed. I removed the comment. No, this is an extra check that was in the python that isn't actually needed. I removed the comment.
|
||||
// DB wasn't created when we initialized headers, reinit
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
if db.TxCounts.Len() == 0 {
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
db.InitHeaders()
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
db.InitTxCounts()
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
}
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
// TODO: assert tx_count not in self.db.tx_counts, f'boom {tx_count} in {len(self.db.tx_counts)} tx counts'
|
||||
if db.TxCounts.Len() != height {
|
||||
log.Error("tx count len:", db.TxCounts.Len(), "height:", height)
|
||||
|
|
@ -759,15 +759,6 @@ func (db *ReadOnlyDBColumnFamily) InitTxCounts() error {
|
|||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
log.Println("len(db.TxCounts), cap(db.TxCounts):", db.TxCounts.Len(), db.TxCounts.Cap())
|
||||
log.Println("Time to get txCounts:", duration)
|
||||
|
||||
// whjy not needs to be len-1 because we start loading with the zero block
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
// and the txcounts start at one???
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
// db.Height = db.TxCounts.Len()
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
// if db.TxCounts.Len() > 0 {
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
// db.Height = db.TxCounts.Len() - 1
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
// } else {
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
// log.Println("db.TxCounts.Len() == 0 ???")
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
// }
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
return nil
|
||||
}
|
||||
|
||||
|
|
|
|||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
|
|
@ -1,5 +1,7 @@
|
|||
package db
|
||||
|
||||
// db_get.go contains the basic access functions to the database.
|
||||
|
||||
import (
|
||||
"encoding/hex"
|
||||
"fmt"
|
||||
|
|
@ -311,11 +313,6 @@ func (db *ReadOnlyDBColumnFamily) GetSupportAmount(claimHash []byte) (uint64, er
|
|||
}
|
||||
|
||||
func (db *ReadOnlyDBColumnFamily) GetTxHash(txNum uint32) ([]byte, error) {
|
||||
/*
|
||||
if self._cache_all_tx_hashes:
|
||||
return self.total_transactions[tx_num]
|
||||
return self.prefix_db.tx_hash.get(tx_num, deserialize_value=False)
|
||||
*/
|
||||
// TODO: caching
|
||||
handle, err := db.EnsureHandle(prefixes.TxHash)
|
||||
if err != nil {
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
package db
|
||||
|
||||
// db_resolve.go contains functions relevant to resolving a claim.
|
||||
|
||||
import (
|
||||
"bytes"
|
||||
"encoding/hex"
|
||||
|
|
@ -38,7 +40,7 @@ func PrepareResolveResult(
|
|||
return nil, err
|
||||
}
|
||||
|
||||
height, createdHeight := db.TxCounts.TxCountsBisectRight(txNum, rootTxNum, BisectRight)
|
||||
height, createdHeight := db.TxCounts.TxCountsBisectRight(txNum, rootTxNum)
|
||||
lastTakeoverHeight := controllingClaim.Height
|
||||
|
||||
expirationHeight := GetExpirationHeight(height)
|
||||
|
|
@ -84,7 +86,7 @@ func PrepareResolveResult(
|
|||
return nil, err
|
||||
}
|
||||
repostTxPostition = repostTxo.Position
|
||||
repostHeight, _ = db.TxCounts.TxCountsBisectRight(repostTxo.TxNum, rootTxNum, BisectRight)
|
||||
repostHeight, _ = db.TxCounts.TxCountsBisectRight(repostTxo.TxNum, rootTxNum)
|
||||
}
|
||||
}
|
||||
|
||||
|
|
@ -120,7 +122,7 @@ func PrepareResolveResult(
|
|||
return nil, err
|
||||
}
|
||||
channelTxPostition = channelVals.Position
|
||||
channelHeight, _ = db.TxCounts.TxCountsBisectRight(channelVals.TxNum, rootTxNum, BisectRight)
|
||||
channelHeight, _ = db.TxCounts.TxCountsBisectRight(channelVals.TxNum, rootTxNum)
|
||||
}
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,12 @@
|
|||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
package db_stack
|
||||
|
||||
// The db_stack package contains the implementation of a generic slice backed stack
|
||||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
// used for tracking various states in the hub, i.e. headers and txcounts
|
||||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
|
||||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
import (
|
||||
"sync"
|
||||
|
||||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
"github.com/lbryio/hub/internal"
|
||||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
)
|
||||
|
||||
type SliceBackedStack struct {
|
||||
|
|
@ -81,16 +86,13 @@ func (s *SliceBackedStack) GetSlice() []interface{} {
|
|||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
}
|
||||
|
||||
// This function is dangerous because it assumes underlying types
|
||||
func (s *SliceBackedStack) TxCountsBisectRight(
|
||||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
txNum, rootTxNum uint32,
|
||||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
bisectFunc func([]interface{}, uint32) uint32,
|
||||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
) (uint32, uint32) {
|
||||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
func (s *SliceBackedStack) TxCountsBisectRight(txNum, rootTxNum uint32) (uint32, uint32) {
|
||||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
s.mut.RLock()
|
||||
defer s.mut.RUnlock()
|
||||
|
||||
txCounts := s.slice[:s.Len()]
|
||||
height := bisectFunc(txCounts, txNum)
|
||||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
createdHeight := bisectFunc(txCounts, rootTxNum)
|
||||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
height := internal.BisectRight(txCounts, txNum)
|
||||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
createdHeight := internal.BisectRight(txCounts, rootTxNum)
|
||||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
|
||||
return height, createdHeight
|
||||
}
|
||||
|
|
|
|||
|
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
every call of this uses the same bisect function. does it make sense to pass it in? every call of this uses the same bisect function. does it make sense to pass it in?
agreed, changed. agreed, changed.
this is already a subpackage of this is already a subpackage of `db`. it should be called `stack`, not `db_stack`
assuming this package is named assuming this package is named `stack`, this should just be `SliceBacked`. no need to put stack in the name again
|
||||
|
|
@ -1,5 +1,7 @@
|
|||
|
should this be named iterator.go or iteroptions.go? it only has options stuff in it should this be named iterator.go or iteroptions.go? it only has options stuff in it
or maybe just options.go or maybe just options.go
should this be named iterator.go or iteroptions.go? it only has options stuff in it should this be named iterator.go or iteroptions.go? it only has options stuff in it
or maybe just options.go or maybe just options.go
|
||||
package db
|
||||
|
||||
// iterator.go contains the implementation for iterators on rocksdb used by the hub
|
||||
|
should this be named iterator.go or iteroptions.go? it only has options stuff in it should this be named iterator.go or iteroptions.go? it only has options stuff in it
or maybe just options.go or maybe just options.go
|
||||
|
||||
|
should this be named iterator.go or iteroptions.go? it only has options stuff in it should this be named iterator.go or iteroptions.go? it only has options stuff in it
or maybe just options.go or maybe just options.go
|
||||
import (
|
||||
"bytes"
|
||||
|
||||
|
|
@ -97,6 +99,7 @@ func (o *IterOptions) WithRawValue(rawValue bool) *IterOptions {
|
|||
|
should this be named iterator.go or iteroptions.go? it only has options stuff in it should this be named iterator.go or iteroptions.go? it only has options stuff in it
or maybe just options.go or maybe just options.go
should this be named iterator.go or iteroptions.go? it only has options stuff in it should this be named iterator.go or iteroptions.go? it only has options stuff in it
or maybe just options.go or maybe just options.go
|
||||
return o
|
||||
}
|
||||
|
||||
// ReadRow reads a row from the db, returns nil when no more rows are available.
|
||||
|
should this be named iterator.go or iteroptions.go? it only has options stuff in it should this be named iterator.go or iteroptions.go? it only has options stuff in it
or maybe just options.go or maybe just options.go
|
||||
func (opts *IterOptions) ReadRow(prevKey *[]byte) *prefixes.PrefixRowKV {
|
||||
it := opts.It
|
||||
if !it.Valid() {
|
||||
|
|
@ -165,12 +168,12 @@ func (opts *IterOptions) ReadRow(prevKey *[]byte) *prefixes.PrefixRowKV {
|
|||
|
should this be named iterator.go or iteroptions.go? it only has options stuff in it should this be named iterator.go or iteroptions.go? it only has options stuff in it
or maybe just options.go or maybe just options.go
should this be named iterator.go or iteroptions.go? it only has options stuff in it should this be named iterator.go or iteroptions.go? it only has options stuff in it
or maybe just options.go or maybe just options.go
|
||||
return kv
|
||||
}
|
||||
|
||||
// StopIteration returns true if we've hit the criteria to end iteration on this key
|
||||
|
should this be named iterator.go or iteroptions.go? it only has options stuff in it should this be named iterator.go or iteroptions.go? it only has options stuff in it
or maybe just options.go or maybe just options.go
|
||||
func (o *IterOptions) StopIteration(key []byte) bool {
|
||||
if key == nil {
|
||||
return false
|
||||
}
|
||||
|
||||
// TODO: Look at not doing floating point conversions for this
|
||||
|
should this be named iterator.go or iteroptions.go? it only has options stuff in it should this be named iterator.go or iteroptions.go? it only has options stuff in it
or maybe just options.go or maybe just options.go
|
||||
maxLenStop := intMin(len(key), len(o.Stop))
|
||||
maxLenStart := intMin(len(key), len(o.Start))
|
||||
if o.Stop != nil &&
|
||||
|
|
|
|||
|
should this be named iterator.go or iteroptions.go? it only has options stuff in it should this be named iterator.go or iteroptions.go? it only has options stuff in it
or maybe just options.go or maybe just options.go
should this be named iterator.go or iteroptions.go? it only has options stuff in it should this be named iterator.go or iteroptions.go? it only has options stuff in it
or maybe just options.go or maybe just options.go
|
||||
|
|
@ -181,12 +181,7 @@ func (v *DBStateValue) PackValue() []byte {
|
|||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
histFlushCount = (OnesCompTwiddle32 - uint32(v.HistFlushCount))
|
||||
compFlushCount = (OnesCompTwiddle32 - uint32(v.CompFlushCount))
|
||||
compCursor = (OnesCompTwiddle32 - uint32(v.CompCursor))
|
||||
// if v.HistFlushCount < 0 {
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
// }
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
// if v.CompFlushCount < 0 {
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
// }
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
// if v.CompCursor < 0 {
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
// }
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
binary.BigEndian.PutUint32(value[32+4+4+32+4+4+1+1:], histFlushCount)
|
||||
binary.BigEndian.PutUint32(value[32+4+4+32+4+4+1+1+4:], compFlushCount)
|
||||
binary.BigEndian.PutUint32(value[32+4+4+32+4+4+1+1+4+4:], compCursor)
|
||||
|
|
@ -689,6 +684,13 @@ type BlockTxsValue struct {
|
|||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
TxHashes [][]byte `json:"tx_hashes"`
|
||||
}
|
||||
|
||||
func (k *BlockTxsKey) NewBlockTxsKey(height uint32) *BlockTxsKey {
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
return &BlockTxsKey{
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
Prefix: []byte{BlockTXs},
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
Height: height,
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
}
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
}
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
func (k *BlockTxsKey) PackKey() []byte {
|
||||
prefixLen := 1
|
||||
// b'>L'
|
||||
|
|
|
|||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
10
internal/sort.go
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
|
seems like seems like `search` is a better name than `sort`
I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense. I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense.
seems like seems like `search` is a better name than `sort`
I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense. I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense.
|
||||
package internal
|
||||
|
seems like seems like `search` is a better name than `sort`
I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense. I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense.
|
||||
|
||||
|
seems like seems like `search` is a better name than `sort`
I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense. I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense.
|
||||
import "sort"
|
||||
|
seems like seems like `search` is a better name than `sort`
I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense. I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense.
|
||||
|
||||
|
seems like seems like `search` is a better name than `sort`
I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense. I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense.
|
||||
// BisectRight returns the index of the first element in the list that is greater than or equal to the value.
|
||||
|
seems like seems like `search` is a better name than `sort`
I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense. I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense.
|
||||
// https://stackoverflow.com/questions/29959506/is-there-a-go-analog-of-pythons-bisect-module
|
||||
|
seems like seems like `search` is a better name than `sort`
I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense. I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense.
|
||||
func BisectRight(arr []interface{}, val uint32) uint32 {
|
||||
|
seems like seems like `search` is a better name than `sort`
I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense. I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense.
|
||||
i := sort.Search(len(arr), func(i int) bool { return arr[i].(uint32) >= val })
|
||||
|
seems like seems like `search` is a better name than `sort`
I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense. I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense.
|
||||
return uint32(i)
|
||||
|
seems like seems like `search` is a better name than `sort`
I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense. I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense.
|
||||
}
|
||||
|
seems like seems like `search` is a better name than `sort`
I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense. I'd normally agree, function I'm thinly wrapping comes straight from Go's "sort" package, so I thought this might make more sense.
|
||||
110
main.go
|
|
@ -1,15 +1,10 @@
|
|||
package main
|
||||
|
||||
import (
|
||||
"bytes"
|
||||
"context"
|
||||
"encoding/hex"
|
||||
"fmt"
|
||||
"time"
|
||||
|
||||
"github.com/lbryio/hub/db"
|
||||
"github.com/lbryio/hub/db/prefixes"
|
||||
"github.com/lbryio/hub/internal"
|
||||
pb "github.com/lbryio/hub/protobuf/go"
|
||||
"github.com/lbryio/hub/server"
|
||||
|
prolly here just for profiling, right? prolly here just for profiling, right?
yeah yeah
|
||||
"github.com/lbryio/lbry.go/v2/extras/util"
|
||||
|
|
@ -33,8 +28,6 @@ func main() {
|
|||
ctxWCancel, cancel := context.WithCancel(ctx)
|
||||
defer cancel()
|
||||
|
||||
// TODO: Figure out if / where we need signal handling
|
||||
|
||||
initsignals()
|
||||
interrupt := interruptListener()
|
||||
|
||||
|
|
@ -53,109 +46,6 @@ func main() {
|
|||
|
||||
<-interrupt
|
||||
return
|
||||
} else if args.CmdType == server.DBCmd {
|
||||
options := &db.IterOptions{
|
||||
FillCache: false,
|
||||
Prefix: []byte{prefixes.SupportAmount},
|
||||
Start: nil,
|
||||
Stop: nil,
|
||||
IncludeStart: true,
|
||||
IncludeStop: false,
|
||||
IncludeKey: true,
|
||||
IncludeValue: true,
|
||||
RawKey: true,
|
||||
RawValue: true,
|
||||
}
|
||||
|
||||
dbVal, err := db.GetDB("/mnt/d/data/wallet/lbry-rocksdb/")
|
||||
if err != nil {
|
||||
log.Fatalln(err)
|
||||
}
|
||||
|
||||
db.ReadWriteRawN(dbVal, options, "./testdata/support_amount.csv", 10)
|
||||
|
||||
return
|
||||
} else if args.CmdType == server.DBCmd2 {
|
||||
pxs := prefixes.GetPrefixes()
|
||||
for _, prefix := range pxs {
|
||||
//var rawPrefix byte = prefixes.ClaimExpiration
|
||||
|
||||
//prefix := []byte{rawPrefix}
|
||||
columnFamily := string(prefix)
|
||||
options := &db.IterOptions{
|
||||
FillCache: false,
|
||||
Prefix: prefix,
|
||||
Start: nil,
|
||||
Stop: nil,
|
||||
IncludeStart: true,
|
||||
IncludeStop: false,
|
||||
IncludeKey: true,
|
||||
IncludeValue: true,
|
||||
RawKey: true,
|
||||
RawValue: true,
|
||||
}
|
||||
|
||||
dbVal, handles, err := db.GetDBCF("/mnt/d/data/snapshot_1072108/lbry-rocksdb/", columnFamily)
|
||||
if err != nil {
|
||||
log.Fatalln(err)
|
||||
}
|
||||
|
||||
options.CfHandle = handles[1]
|
||||
var n = 10
|
||||
if bytes.Equal(prefix, []byte{prefixes.Undo}) || bytes.Equal(prefix, []byte{prefixes.DBState}) {
|
||||
n = 1
|
||||
}
|
||||
|
||||
db.ReadWriteRawNCF(dbVal, options, fmt.Sprintf("./testdata/%s.csv", columnFamily), n)
|
||||
}
|
||||
|
||||
return
|
||||
} else if args.CmdType == server.DBCmd3 {
|
||||
// streamHash, _ := hex.DecodeString("9a0ed686ecdad9b6cb965c4d6681c02f0bbc66a6")
|
||||
channelHash, _ := hex.DecodeString("2556ed1cab9d17f2a9392030a9ad7f5d138f11bd")
|
||||
name := internal.NormalizeName("@Styxhexenhammer666")
|
||||
// txNum := uint32(0x6284e3)
|
||||
// position := uint16(0x0)
|
||||
// For stream claim
|
||||
// txNum := uint32(0x369e2b2)
|
||||
// position := uint16(0x0)
|
||||
// typ := uint8(prefixes.ACTIVATED_CLAIM_TXO_TYPE)
|
||||
var rawPrefix byte = prefixes.ChannelToClaim
|
||||
var startRaw []byte = nil
|
||||
prefix := []byte{rawPrefix}
|
||||
columnFamily := string(prefix)
|
||||
// start := prefixes.NewClaimTakeoverKey(name)
|
||||
// start := prefixes.NewActiveAmountKey(channelHash, prefixes.ACTIVATED_SUPPORT_TXO_TYPE, 0)
|
||||
start := prefixes.NewChannelToClaimKey(channelHash, name)
|
||||
startRaw = start.PackKey()
|
||||
// start := &prefixes.ChannelCountKey{
|
||||
// Prefix: prefix,
|
||||
// ChannelHash: channelHash,
|
||||
// }
|
||||
// startRaw := prefixes.ChannelCountKeyPackPartial(start, 1)
|
||||
// startRaw := start.PackKey()
|
||||
options := &db.IterOptions{
|
||||
FillCache: false,
|
||||
Prefix: prefix,
|
||||
Start: startRaw,
|
||||
Stop: nil,
|
||||
IncludeStart: true,
|
||||
IncludeStop: false,
|
||||
IncludeKey: true,
|
||||
IncludeValue: true,
|
||||
RawKey: true,
|
||||
RawValue: true,
|
||||
}
|
||||
|
||||
dbVal, handles, err := db.GetDBCF("/mnt/d/data/snapshot_1072108/lbry-rocksdb/", columnFamily)
|
||||
if err != nil {
|
||||
log.Fatalln(err)
|
||||
}
|
||||
|
||||
options.CfHandle = handles[1]
|
||||
|
||||
db.ReadWriteRawNColumnFamilies(dbVal, options, fmt.Sprintf("./testdata/%s_resolve.csv", columnFamily), 1)
|
||||
return
|
||||
}
|
||||
|
||||
conn, err := grpc.Dial("localhost:"+args.Port,
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ func TestUDPPing(t *testing.T) {
|
|||
for _, tt := range tests {
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
|
||||
toAddr := "spv17.lbry.com"
|
||||
toAddr := "spv15.lbry.com"
|
||||
toPort := "50001"
|
||||
|
||||
pong, err := server.UDPPing(toAddr, toPort)
|
||||
|
|
|
|||
no need to start these with N
and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families
this can be unexported
still need this?
typo
👀