rocksdb #29
244
db/db.go
|
|
@ -3,8 +3,6 @@ package db
|
||||||
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 (
|
import (
|
||||||
"bytes"
|
"bytes"
|
||||||
"encoding/hex"
|
"encoding/hex"
|
||||||
"encoding/json"
|
|
||||||
|
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.
|
|||||||
"fmt"
|
|
||||||
|
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"
|
"log"
|
||||||
"math"
|
"math"
|
||||||
"os"
|
"os"
|
||||||
|
|
@ -13,6 +11,60 @@ import (
|
||||||
|
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.
|
|||||||
"github.com/linxGnu/grocksdb"
|
"github.com/linxGnu/grocksdb"
|
||||||
)
|
)
|
||||||
|
|
||||||
|
type ResolveResult struct {
|
||||||
|
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.
|
|||||||
|
Name 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.
|
|||||||
|
NormalizedName 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.
|
|||||||
|
ClaimHash []byte
|
||||||
|
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.
|
|||||||
|
TxNum int
|
||||||
|
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.
|
|||||||
|
Position int
|
||||||
|
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.
|
|||||||
|
TxHash []byte
|
||||||
|
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.
|
|||||||
|
Height int
|
||||||
|
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.
|
|||||||
|
Amount int
|
||||||
|
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.
|
|||||||
|
ShortUrl 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.
|
|||||||
|
IsControlling bool
|
||||||
|
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.
|
|||||||
|
CanonicalUrl 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.
|
|||||||
|
CreationHeight int
|
||||||
|
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.
|
|||||||
|
ActivationHeight int
|
||||||
|
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.
|
|||||||
|
ExpirationHeight int
|
||||||
|
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.
|
|||||||
|
EffectiveAmount int
|
||||||
|
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.
|
|||||||
|
SupportAmount int
|
||||||
|
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.
|
|||||||
|
Reposted int
|
||||||
|
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.
|
|||||||
|
LastTakeoverHeight int
|
||||||
|
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.
|
|||||||
|
ClaimsInChannel int
|
||||||
|
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.
|
|||||||
|
ChannelHash []byte
|
||||||
|
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.
|
|||||||
|
RepostedClaimHash []byte
|
||||||
|
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.
|
|||||||
|
SignatureValid bool
|
||||||
|
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.
|
|||||||
|
type ResolveError struct {
|
||||||
|
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.
|
|||||||
|
Error 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.
|
|||||||
|
|
||||||
|
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.
|
|||||||
|
type OptionalResolveResultOrError interface {
|
||||||
|
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.
|
|||||||
|
GetResult() *ResolveResult
|
||||||
|
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.
|
|||||||
|
GetError() *ResolveError
|
||||||
|
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.
|
|||||||
|
type optionalResolveResultOrError struct {
|
||||||
|
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.
|
|||||||
|
res *ResolveResult
|
||||||
|
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.
|
|||||||
|
err *ResolveError
|
||||||
|
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.
|
|||||||
|
func (x *optionalResolveResultOrError) GetResult() *ResolveResult {
|
||||||
|
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 x.res
|
||||||
|
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.
|
|||||||
|
func (x *optionalResolveResultOrError) GetError() *ResolveError {
|
||||||
|
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 x.err
|
||||||
|
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.
|
|||||||
|
type ExpandedResolveResult struct {
|
||||||
|
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.
fyi this kind of stuff is usually done with sync.WaitGroup, but your way seems fine too fyi this kind of stuff is usually done with sync.WaitGroup, but your way seems fine too
|
|||||||
|
Stream OptionalResolveResultOrError
|
||||||
|
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.
|
|||||||
|
Channel OptionalResolveResultOrError
|
||||||
|
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.
|
|||||||
|
Repost OptionalResolveResultOrError
|
||||||
|
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.
|
|||||||
|
RepostedChannel OptionalResolveResultOrError
|
||||||
|
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.
|
|||||||
type IterOptions struct {
|
type IterOptions struct {
|
||||||
FillCache bool
|
FillCache bool
|
||||||
|
all these hashes should be chainhash.Hash type all these hashes should be chainhash.Hash type
|
|||||||
Prefix []byte
|
Prefix []byte
|
||||||
|
|
@ -24,6 +76,7 @@ type IterOptions struct {
|
||||||
|
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.
|
|||||||
IncludeValue bool
|
IncludeValue bool
|
||||||
RawKey bool
|
RawKey bool
|
||||||
RawValue bool
|
RawValue bool
|
||||||
|
It *grocksdb.Iterator
|
||||||
|
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.
|
|||||||
}
|
}
|
||||||
|
|
||||||
// NewIterateOptions creates a defualt options structure for a db iterator.
|
// NewIterateOptions creates a defualt options structure for a db iterator.
|
||||||
|
|
@ -39,6 +92,7 @@ func NewIterateOptions() *IterOptions {
|
||||||
|
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.
|
|||||||
IncludeValue: false,
|
IncludeValue: false,
|
||||||
RawKey: false,
|
RawKey: false,
|
||||||
RawValue: false,
|
RawValue: false,
|
||||||
|
It: 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.
|
|||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
@ -92,46 +146,51 @@ func (o *IterOptions) WithRawValue(rawValue bool) *IterOptions {
|
||||||
|
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 o
|
return o
|
||||||
}
|
}
|
||||||
|
|
||||||
func Iter(db *grocksdb.DB, opts *IterOptions) <-chan *prefixes.PrefixRowKV {
|
func (o *IterOptions) StopIteration(key []byte) bool {
|
||||||
|
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.
|
|||||||
ch := make(chan *prefixes.PrefixRowKV)
|
|
||||||
|
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.
|
|||||||
ro := grocksdb.NewDefaultReadOptions()
|
|
||||||
|
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.
|
|||||||
ro.SetFillCache(opts.FillCache)
|
|
||||||
|
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.
|
|||||||
it := db.NewIterator(ro)
|
|
||||||
|
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.
|
|||||||
it.Seek(opts.Prefix)
|
|
||||||
|
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 opts.Start != 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.
|
|||||||
it.Seek(opts.Start)
|
|
||||||
|
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.
|
|||||||
stopIteration := func(key []byte) bool {
|
|
||||||
|
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 key == nil {
|
if key == nil {
|
||||||
return false
|
return false
|
||||||
}
|
}
|
||||||
|
|
||||||
maxLen := int(math.Min(float64(len(key)), float64(len(opts.Stop))))
|
maxLen := int(math.Min(float64(len(key)), float64(len(o.Stop))))
|
||||||
|
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.
|
|||||||
if opts.Stop != nil &&
|
if o.Stop != 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.
|
|||||||
(bytes.HasPrefix(key, opts.Stop) || bytes.Compare(opts.Stop, key[:maxLen]) < 0) {
|
(bytes.HasPrefix(key, o.Stop) || bytes.Compare(o.Stop, key[:maxLen]) < 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.
|
|||||||
return true
|
return true
|
||||||
} else if opts.Start != nil &&
|
} else if o.Start != 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.
|
|||||||
bytes.Compare(opts.Start, key[:len(opts.Start)]) > 0 {
|
bytes.Compare(o.Start, key[:len(o.Start)]) > 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.
|
|||||||
return true
|
return true
|
||||||
} else if opts.Prefix != nil && !bytes.HasPrefix(key, opts.Prefix) {
|
} else if o.Prefix != nil && !bytes.HasPrefix(key, o.Prefix) {
|
||||||
|
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 true
|
return true
|
||||||
}
|
}
|
||||||
|
|
||||||
return false
|
return false
|
||||||
|
}
|
||||||
|
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.
|
|||||||
|
func ParseURL(url string) (stream string, channel string, err 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.
|
|||||||
|
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.
|
|||||||
|
|
||||||
|
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 Resolve(db *grocksdb.DB, url string) *ExpandedResolveResult {
|
||||||
|
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.
|
|||||||
|
var res = &ExpandedResolveResult{
|
||||||
|
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.
|
|||||||
|
Stream: 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.
|
|||||||
|
Channel: 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.
|
|||||||
|
Repost: 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.
|
|||||||
|
RepostedChannel: 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.
|
|||||||
}
|
}
|
||||||
|
|
||||||
go func() {
|
stream, channel, err := ParseURL(url)
|
||||||
|
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.
|
|||||||
defer it.Close()
|
if err != 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.
|
|||||||
defer close(ch)
|
res.Stream = &optionalResolveResultOrError{
|
||||||
|
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.
|
|||||||
|
err: &ResolveError{err},
|
||||||
|
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.
|
|||||||
if !opts.IncludeStart {
|
|
||||||
|
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.
|
|||||||
it.Next()
|
|
||||||
|
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.
|
|||||||
}
|
}
|
||||||
var prevKey []byte = nil
|
return res
|
||||||
|
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.
|
|||||||
for ; !stopIteration(prevKey) && it.Valid(); it.Next() {
|
}
|
||||||
|
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.
|
|||||||
|
log.Println(stream, channel)
|
||||||
|
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 res
|
||||||
|
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.
|
|||||||
|
func (opts *IterOptions) ReadRow(ch chan *prefixes.PrefixRowKV, prevKey *[]byte) bool {
|
||||||
|
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.
|
|||||||
|
it := opts.It
|
||||||
|
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.
|
|||||||
key := it.Key()
|
key := it.Key()
|
||||||
keyData := key.Data()
|
keyData := key.Data()
|
||||||
keyLen := len(keyData)
|
keyLen := len(keyData)
|
||||||
|
|
@ -145,8 +204,8 @@ func Iter(db *grocksdb.DB, opts *IterOptions) <-chan *prefixes.PrefixRowKV {
|
||||||
|
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.
|
|||||||
|
|
||||||
// We need to check the current key is we're not including the stop
|
// We need to check the current key is we're not including the stop
|
||||||
// key.
|
// key.
|
||||||
if !opts.IncludeStop && stopIteration(keyData) {
|
if !opts.IncludeStop && opts.StopIteration(keyData) {
|
||||||
|
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
|
return false
|
||||||
|
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.
|
|||||||
}
|
}
|
||||||
|
|
||||||
// We have to copy the key no matter what because we need to check
|
// We have to copy the key no matter what because we need to check
|
||||||
|
|
@ -154,11 +213,7 @@ func Iter(db *grocksdb.DB, opts *IterOptions) <-chan *prefixes.PrefixRowKV {
|
||||||
|
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.
|
|||||||
newKeyData := make([]byte, keyLen)
|
newKeyData := make([]byte, keyLen)
|
||||||
copy(newKeyData, keyData)
|
copy(newKeyData, keyData)
|
||||||
if opts.IncludeKey && !opts.RawKey {
|
if opts.IncludeKey && !opts.RawKey {
|
||||||
//unpackKeyFnValue := reflect.ValueOf(KeyUnpackFunc)
|
outKey, err = prefixes.UnpackGenericKey(newKeyData)
|
||||||
|
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.
|
|||||||
//keyArgs := []reflect.Value{reflect.ValueOf(newKeyData)}
|
|
||||||
|
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.
|
|||||||
//unpackKeyFnResult := unpackKeyFnValue.Call(keyArgs)
|
|
||||||
|
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.
|
|||||||
//outKey = unpackKeyFnResult[0].Interface()
|
|
||||||
|
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.
|
|||||||
_, outKey, err = prefixes.UnpackGenericKey(newKeyData)
|
|
||||||
|
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 err != nil {
|
if err != nil {
|
||||||
log.Println(err)
|
log.Println(err)
|
||||||
}
|
}
|
||||||
|
|
@ -171,12 +226,8 @@ func Iter(db *grocksdb.DB, opts *IterOptions) <-chan *prefixes.PrefixRowKV {
|
||||||
|
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.
|
|||||||
if opts.IncludeValue {
|
if opts.IncludeValue {
|
||||||
newValueData := make([]byte, valueLen)
|
newValueData := make([]byte, valueLen)
|
||||||
copy(newValueData, valueData)
|
copy(newValueData, valueData)
|
||||||
//unpackValueFnValue := reflect.ValueOf(ValueUnpackFunc)
|
|
||||||
|
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.
|
|||||||
//valueArgs := []reflect.Value{reflect.ValueOf(newValueData)}
|
|
||||||
|
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.
|
|||||||
//unpackValueFnResult := unpackValueFnValue.Call(valueArgs)
|
|
||||||
|
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.
|
|||||||
//outValue = unpackValueFnResult[0].Interface()
|
|
||||||
|
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 !opts.RawValue {
|
if !opts.RawValue {
|
||||||
_, outValue, err = prefixes.UnpackGenericValue(newKeyData, newValueData)
|
outValue, err = prefixes.UnpackGenericValue(newKeyData, newValueData)
|
||||||
|
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.
|
|||||||
if err != nil {
|
if err != nil {
|
||||||
log.Println(err)
|
log.Println(err)
|
||||||
}
|
}
|
||||||
|
|
@ -192,8 +243,37 @@ func Iter(db *grocksdb.DB, opts *IterOptions) <-chan *prefixes.PrefixRowKV {
|
||||||
|
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.
|
|||||||
Key: outKey,
|
Key: outKey,
|
||||||
Value: outValue,
|
Value: outValue,
|
||||||
}
|
}
|
||||||
prevKey = newKeyData
|
*prevKey = newKeyData
|
||||||
|
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 true
|
||||||
|
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.
|
|||||||
|
func Iter(db *grocksdb.DB, opts *IterOptions) <-chan *prefixes.PrefixRowKV {
|
||||||
|
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.
|
|||||||
|
ch := make(chan *prefixes.PrefixRowKV)
|
||||||
|
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.
|
|||||||
|
ro := grocksdb.NewDefaultReadOptions()
|
||||||
|
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.
|
|||||||
|
ro.SetFillCache(opts.FillCache)
|
||||||
|
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.
|
|||||||
|
it := db.NewIterator(ro)
|
||||||
|
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.
|
|||||||
|
opts.It = it
|
||||||
|
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.
|
|||||||
|
it.Seek(opts.Prefix)
|
||||||
|
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 opts.Start != 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.
|
|||||||
|
it.Seek(opts.Start)
|
||||||
|
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.
|
|||||||
|
go func() {
|
||||||
|
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.
|
|||||||
|
defer it.Close()
|
||||||
|
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.
|
|||||||
|
defer close(ch)
|
||||||
|
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.
|
|||||||
|
var prevKey []byte = 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.
|
|||||||
|
if !opts.IncludeStart {
|
||||||
|
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.
|
|||||||
|
it.Next()
|
||||||
|
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.
|
|||||||
|
if !it.Valid() && opts.IncludeStop {
|
||||||
|
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.
|
|||||||
|
opts.ReadRow(ch, &prevKey)
|
||||||
|
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.
|
|||||||
|
for ; !opts.StopIteration(prevKey) && it.Valid(); it.Next() {
|
||||||
|
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.
|
|||||||
|
opts.ReadRow(ch, &prevKey)
|
||||||
|
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.
|
|||||||
}
|
}
|
||||||
}()
|
}()
|
||||||
|
|
||||||
|
|
@ -202,7 +282,6 @@ func Iter(db *grocksdb.DB, opts *IterOptions) <-chan *prefixes.PrefixRowKV {
|
||||||
|
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.
|
|||||||
|
|
||||||
func GetDB(name string) (*grocksdb.DB, error) {
|
func GetDB(name string) (*grocksdb.DB, error) {
|
||||||
opts := grocksdb.NewDefaultOptions()
|
opts := grocksdb.NewDefaultOptions()
|
||||||
// db, err := grocksdb.OpenDb(opts, name)
|
|
||||||
|
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, err := grocksdb.OpenDbAsSecondary(opts, name, "asdf")
|
db, err := grocksdb.OpenDbAsSecondary(opts, name, "asdf")
|
||||||
if err != nil {
|
if err != nil {
|
||||||
return nil, err
|
return nil, err
|
||||||
|
|
@ -242,65 +321,6 @@ func ReadPrefixN(db *grocksdb.DB, prefix []byte, n int) []*prefixes.PrefixRowKV
|
||||||
|
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 res
|
return res
|
||||||
}
|
}
|
||||||
|
|
||||||
func OpenDB(name string, start string) int {
|
|
||||||
|
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.
|
|||||||
// Read db
|
|
||||||
|
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.
|
|||||||
opts := grocksdb.NewDefaultOptions()
|
|
||||||
|
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, err := grocksdb.OpenDb(opts, name)
|
|
||||||
|
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 err != 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.
|
|||||||
log.Println(err)
|
|
||||||
|
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.
|
|||||||
defer db.Close()
|
|
||||||
|
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.
|
|||||||
ro := grocksdb.NewDefaultReadOptions()
|
|
||||||
|
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.
|
|||||||
ro.SetFillCache(false)
|
|
||||||
|
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(db.Name())
|
|
||||||
|
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.
|
|||||||
it := db.NewIterator(ro)
|
|
||||||
|
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.
|
|||||||
defer it.Close()
|
|
||||||
|
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.
|
|||||||
var i = 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.
|
|||||||
it.Seek([]byte(start))
|
|
||||||
|
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.
|
|||||||
for ; it.Valid(); it.Next() {
|
|
||||||
|
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.
|
|||||||
key := it.Key()
|
|
||||||
|
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.
|
|||||||
value := it.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.
|
|||||||
|
|
||||||
|
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.
|
|||||||
fmt.Printf("Key: %v Value: %v\n", hex.EncodeToString(key.Data()), hex.EncodeToString(value.Data()))
|
|
||||||
|
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.
|
|||||||
key.Free()
|
|
||||||
|
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.
|
|||||||
value.Free()
|
|
||||||
|
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++
|
|
||||||
|
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.
|
|||||||
if err := it.Err(); err != 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.
|
|||||||
log.Println(err)
|
|
||||||
|
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 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.
|
|||||||
func OpenAndWriteDB(db *grocksdb.DB, options *IterOptions, out 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.
|
|||||||
ch := Iter(db, options)
|
|
||||||
|
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.
|
|||||||
var i = 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.
|
|||||||
for kv := range ch {
|
|
||||||
|
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.
|
|||||||
key := kv.Key.(*prefixes.UTXOKey)
|
|
||||||
|
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.
|
|||||||
value := kv.Value.(*prefixes.UTXOValue)
|
|
||||||
|
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.
|
|||||||
keyMarshal, err := json.Marshal(key)
|
|
||||||
|
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 err != 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.
|
|||||||
log.Println(err)
|
|
||||||
|
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.
|
|||||||
valMarshal, err := json.Marshal(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.
|
|||||||
if err != 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.
|
|||||||
log.Println(err)
|
|
||||||
|
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.
|
|||||||
log.Println(string(keyMarshal), string(valMarshal))
|
|
||||||
|
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.
|
|||||||
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.
|
|||||||
|
|
||||||
|
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 ReadWriteRawN(db *grocksdb.DB, options *IterOptions, out string, n int) {
|
func ReadWriteRawN(db *grocksdb.DB, options *IterOptions, out string, n int) {
|
||||||
|
|
||||||
options.RawKey = true
|
options.RawKey = true
|
||||||
|
|
@ -335,27 +355,15 @@ func ReadWriteRawN(db *grocksdb.DB, options *IterOptions, out string, n int) {
|
||||||
|
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.
|
|||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
func GenerateTestData() {
|
func GenerateTestData(prefix byte, fileName 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.
|
|||||||
dbVal, err := GetDB("/mnt/d/data/wallet/lbry-rocksdb/")
|
dbVal, err := GetDB("/mnt/d/data/wallet/lbry-rocksdb/")
|
||||||
if err != nil {
|
if err != nil {
|
||||||
log.Fatalln(err)
|
log.Fatalln(err)
|
||||||
}
|
}
|
||||||
|
|
||||||
// options := &IterOptions{
|
|
||||||
|
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.
|
|||||||
// FillCache: false,
|
|
||||||
|
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.
|
|||||||
// Prefix: []byte{prefixes.HashXUTXO},
|
|
||||||
|
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.
|
|||||||
// Start: 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.
|
|||||||
// Stop: 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.
|
|||||||
// IncludeStart: true,
|
|
||||||
|
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.
|
|||||||
// IncludeStop: false,
|
|
||||||
|
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.
|
|||||||
// IncludeKey: true,
|
|
||||||
|
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.
|
|||||||
// IncludeValue: true,
|
|
||||||
|
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.
|
|||||||
// RawKey: true,
|
|
||||||
|
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.
|
|||||||
// RawValue: true,
|
|
||||||
|
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.
|
|||||||
options := NewIterateOptions()
|
options := NewIterateOptions()
|
||||||
options.WithRawKey(true).WithRawValue(true)
|
options.WithRawKey(true).WithRawValue(true).WithIncludeValue(true)
|
||||||
|
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.
|
|||||||
options.WithPrefix([]byte{prefixes.HashXUTXO})
|
options.WithPrefix([]byte{prefix})
|
||||||
|
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.
|
|||||||
|
|
||||||
ReadWriteRawN(dbVal, options, "./resources/hashx_utxo.csv", 10)
|
ReadWriteRawN(dbVal, options, fileName, 10)
|
||||||
|
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.
|
|||||||
}
|
}
|
||||||
|
needs fixing? needs fixing?
|
|||||||
|
|
|
||||||
|
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.
|
|||||||
|
|
@ -3616,363 +3616,363 @@ func UTXOValueUnpack(value []byte) *UTXOValue {
|
||||||
|
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 generic(voidstar interface{}, firstByte byte, function byte, functionName string) (byte, interface{}, error) {
|
func generic(voidstar interface{}, firstByte byte, function byte, functionName string) (interface{}, error) {
|
||||||
|
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.
|
|||||||
var data []byte
|
var data []byte
|
||||||
if function < 2 {
|
if function < 2 {
|
||||||
data = voidstar.([]byte)
|
data = voidstar.([]byte)
|
||||||
}
|
}
|
||||||
switch uint16(firstByte) | uint16(function)<<8 {
|
switch uint16(firstByte) | uint16(function)<<8 {
|
||||||
case ClaimToSupport:
|
case ClaimToSupport:
|
||||||
return ClaimToSupport, ClaimToSupportKeyUnpack(data), nil
|
return ClaimToSupportKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ClaimToSupport | 1<<8:
|
case ClaimToSupport | 1<<8:
|
||||||
return ClaimToSupport, ClaimToSupportValueUnpack(data), nil
|
return ClaimToSupportValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ClaimToSupport | 2<<8:
|
case ClaimToSupport | 2<<8:
|
||||||
return ClaimToSupport, voidstar.(*ClaimToSupportKey).PackKey(), nil
|
return voidstar.(*ClaimToSupportKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case ClaimToSupport | 3<<8:
|
case ClaimToSupport | 3<<8:
|
||||||
return ClaimToSupport, voidstar.(*ClaimToSupportValue).PackValue(), nil
|
return voidstar.(*ClaimToSupportValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case ClaimToSupport | 4<<8:
|
case ClaimToSupport | 4<<8:
|
||||||
return ClaimToSupport, ClaimToSupportKeyPackPartialKey(voidstar.(*ClaimToSupportKey)), nil
|
return ClaimToSupportKeyPackPartialKey(voidstar.(*ClaimToSupportKey)), nil
|
||||||
|
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.
|
|||||||
case SupportToClaim:
|
case SupportToClaim:
|
||||||
return SupportToClaim, SupportToClaimKeyUnpack(data), nil
|
return SupportToClaimKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case SupportToClaim | 1<<8:
|
case SupportToClaim | 1<<8:
|
||||||
return SupportToClaim, SupportToClaimValueUnpack(data), nil
|
return SupportToClaimValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case SupportToClaim | 2<<8:
|
case SupportToClaim | 2<<8:
|
||||||
return SupportToClaim, voidstar.(*SupportToClaimKey).PackKey(), nil
|
return voidstar.(*SupportToClaimKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case SupportToClaim | 3<<8:
|
case SupportToClaim | 3<<8:
|
||||||
return SupportToClaim, voidstar.(*SupportToClaimValue).PackValue(), nil
|
return voidstar.(*SupportToClaimValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case SupportToClaim | 4<<8:
|
case SupportToClaim | 4<<8:
|
||||||
return SupportToClaim, SupportToClaimKeyPackPartialKey(voidstar.(*SupportToClaimKey)), nil
|
return SupportToClaimKeyPackPartialKey(voidstar.(*SupportToClaimKey)), nil
|
||||||
|
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.
|
|||||||
case ClaimToTXO:
|
case ClaimToTXO:
|
||||||
return ClaimToTXO, ClaimToTXOKeyUnpack(data), nil
|
return ClaimToTXOKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ClaimToTXO | 1<<8:
|
case ClaimToTXO | 1<<8:
|
||||||
return ClaimToTXO, ClaimToTXOValueUnpack(data), nil
|
return ClaimToTXOValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ClaimToTXO | 2<<8:
|
case ClaimToTXO | 2<<8:
|
||||||
return ClaimToTXO, voidstar.(*ClaimToTXOKey).PackKey(), nil
|
return voidstar.(*ClaimToTXOKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case ClaimToTXO | 3<<8:
|
case ClaimToTXO | 3<<8:
|
||||||
return ClaimToTXO, voidstar.(*ClaimToTXOValue).PackValue(), nil
|
return voidstar.(*ClaimToTXOValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case ClaimToTXO | 4<<8:
|
case ClaimToTXO | 4<<8:
|
||||||
return ClaimToTXO, ClaimToTXOKeyPackPartialKey(voidstar.(*ClaimToTXOKey)), nil
|
return ClaimToTXOKeyPackPartialKey(voidstar.(*ClaimToTXOKey)), nil
|
||||||
|
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.
|
|||||||
case TXOToClaim:
|
case TXOToClaim:
|
||||||
return TXOToClaim, TXOToClaimKeyUnpack(data), nil
|
return TXOToClaimKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case TXOToClaim | 1<<8:
|
case TXOToClaim | 1<<8:
|
||||||
return TXOToClaim, TXOToClaimValueUnpack(data), nil
|
return TXOToClaimValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case TXOToClaim | 2<<8:
|
case TXOToClaim | 2<<8:
|
||||||
return TXOToClaim, voidstar.(*TXOToClaimKey).PackKey(), nil
|
return voidstar.(*TXOToClaimKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case TXOToClaim | 3<<8:
|
case TXOToClaim | 3<<8:
|
||||||
return TXOToClaim, voidstar.(*TXOToClaimValue).PackValue(), nil
|
return voidstar.(*TXOToClaimValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case TXOToClaim | 4<<8:
|
case TXOToClaim | 4<<8:
|
||||||
return TXOToClaim, TXOToClaimKeyPackPartialKey(voidstar.(*TXOToClaimKey)), nil
|
return TXOToClaimKeyPackPartialKey(voidstar.(*TXOToClaimKey)), nil
|
||||||
|
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.
|
|||||||
|
|
||||||
case ClaimToChannel:
|
case ClaimToChannel:
|
||||||
return ClaimToChannel, ClaimToChannelKeyUnpack(data), nil
|
return ClaimToChannelKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ClaimToChannel | 1<<8:
|
case ClaimToChannel | 1<<8:
|
||||||
return ClaimToChannel, ClaimToChannelValueUnpack(data), nil
|
return ClaimToChannelValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ClaimToChannel | 2<<8:
|
case ClaimToChannel | 2<<8:
|
||||||
return ClaimToChannel, voidstar.(*ClaimToChannelKey).PackKey(), nil
|
return voidstar.(*ClaimToChannelKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case ClaimToChannel | 3<<8:
|
case ClaimToChannel | 3<<8:
|
||||||
return ClaimToChannel, voidstar.(*ClaimToChannelValue).PackValue(), nil
|
return voidstar.(*ClaimToChannelValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case ClaimToChannel | 4<<8:
|
case ClaimToChannel | 4<<8:
|
||||||
return ClaimToChannel, ClaimToChannelKeyPackPartialKey(voidstar.(*ClaimToChannelKey)), nil
|
return ClaimToChannelKeyPackPartialKey(voidstar.(*ClaimToChannelKey)), nil
|
||||||
|
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.
|
|||||||
case ChannelToClaim:
|
case ChannelToClaim:
|
||||||
return ChannelToClaim, ChannelToClaimKeyUnpack(data), nil
|
return ChannelToClaimKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ChannelToClaim | 1<<8:
|
case ChannelToClaim | 1<<8:
|
||||||
return ChannelToClaim, ChannelToClaimValueUnpack(data), nil
|
return ChannelToClaimValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ChannelToClaim | 2<<8:
|
case ChannelToClaim | 2<<8:
|
||||||
return ChannelToClaim, voidstar.(*ChannelToClaimKey).PackKey(), nil
|
return voidstar.(*ChannelToClaimKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case ChannelToClaim | 3<<8:
|
case ChannelToClaim | 3<<8:
|
||||||
return ChannelToClaim, voidstar.(*ChannelToClaimValue).PackValue(), nil
|
return voidstar.(*ChannelToClaimValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case ChannelToClaim | 4<<8:
|
case ChannelToClaim | 4<<8:
|
||||||
return ChannelToClaim, ChannelToClaimKeyPackPartialKey(voidstar.(*ChannelToClaimKey)), nil
|
return ChannelToClaimKeyPackPartialKey(voidstar.(*ChannelToClaimKey)), nil
|
||||||
|
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.
|
|||||||
|
|
||||||
case ClaimShortIdPrefix:
|
case ClaimShortIdPrefix:
|
||||||
return ClaimShortIdPrefix, ClaimShortIDKeyUnpack(data), nil
|
return ClaimShortIDKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ClaimShortIdPrefix | 1<<8:
|
case ClaimShortIdPrefix | 1<<8:
|
||||||
return ClaimShortIdPrefix, ClaimShortIDValueUnpack(data), nil
|
return ClaimShortIDValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ClaimShortIdPrefix | 2<<8:
|
case ClaimShortIdPrefix | 2<<8:
|
||||||
return ClaimShortIdPrefix, voidstar.(*ClaimShortIDKey).PackKey(), nil
|
return voidstar.(*ClaimShortIDKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case ClaimShortIdPrefix | 3<<8:
|
case ClaimShortIdPrefix | 3<<8:
|
||||||
return ClaimShortIdPrefix, voidstar.(*ClaimShortIDValue).PackValue(), nil
|
return voidstar.(*ClaimShortIDValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case ClaimShortIdPrefix | 4<<8:
|
case ClaimShortIdPrefix | 4<<8:
|
||||||
return ClaimShortIdPrefix, ClaimShortIDKeyPackPartialKey(voidstar.(*ClaimShortIDKey)), nil
|
return ClaimShortIDKeyPackPartialKey(voidstar.(*ClaimShortIDKey)), nil
|
||||||
|
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.
|
|||||||
case EffectiveAmount:
|
case EffectiveAmount:
|
||||||
return EffectiveAmount, EffectiveAmountKeyUnpack(data), nil
|
return EffectiveAmountKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case EffectiveAmount | 1<<8:
|
case EffectiveAmount | 1<<8:
|
||||||
return EffectiveAmount, EffectiveAmountValueUnpack(data), nil
|
return EffectiveAmountValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case EffectiveAmount | 2<<8:
|
case EffectiveAmount | 2<<8:
|
||||||
return EffectiveAmount, voidstar.(*EffectiveAmountKey).PackKey(), nil
|
return voidstar.(*EffectiveAmountKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case EffectiveAmount | 3<<8:
|
case EffectiveAmount | 3<<8:
|
||||||
return EffectiveAmount, voidstar.(*EffectiveAmountValue).PackValue(), nil
|
return voidstar.(*EffectiveAmountValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case EffectiveAmount | 4<<8:
|
case EffectiveAmount | 4<<8:
|
||||||
return EffectiveAmount, EffectiveAmountKeyPackPartialKey(voidstar.(*EffectiveAmountKey)), nil
|
return EffectiveAmountKeyPackPartialKey(voidstar.(*EffectiveAmountKey)), nil
|
||||||
|
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.
|
|||||||
case ClaimExpiration:
|
case ClaimExpiration:
|
||||||
return ClaimExpiration, ClaimExpirationKeyUnpack(data), nil
|
return ClaimExpirationKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ClaimExpiration | 1<<8:
|
case ClaimExpiration | 1<<8:
|
||||||
return ClaimExpiration, ClaimExpirationValueUnpack(data), nil
|
return ClaimExpirationValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ClaimExpiration | 2<<8:
|
case ClaimExpiration | 2<<8:
|
||||||
return ClaimExpiration, voidstar.(*ClaimExpirationKey).PackKey(), nil
|
return voidstar.(*ClaimExpirationKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case ClaimExpiration | 3<<8:
|
case ClaimExpiration | 3<<8:
|
||||||
return ClaimExpiration, voidstar.(*ClaimExpirationValue).PackValue(), nil
|
return voidstar.(*ClaimExpirationValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case ClaimExpiration | 4<<8:
|
case ClaimExpiration | 4<<8:
|
||||||
return ClaimExpiration, ClaimExpirationKeyPackPartialKey(voidstar.(*ClaimExpirationKey)), nil
|
return ClaimExpirationKeyPackPartialKey(voidstar.(*ClaimExpirationKey)), nil
|
||||||
|
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.
|
|||||||
|
|
||||||
case ClaimTakeover:
|
case ClaimTakeover:
|
||||||
return ClaimTakeover, ClaimTakeoverKeyUnpack(data), nil
|
return ClaimTakeoverKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ClaimTakeover | 1<<8:
|
case ClaimTakeover | 1<<8:
|
||||||
return ClaimTakeover, ClaimTakeoverValueUnpack(data), nil
|
return ClaimTakeoverValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ClaimTakeover | 2<<8:
|
case ClaimTakeover | 2<<8:
|
||||||
return ClaimTakeover, voidstar.(*ClaimTakeoverKey).PackKey(), nil
|
return voidstar.(*ClaimTakeoverKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case ClaimTakeover | 3<<8:
|
case ClaimTakeover | 3<<8:
|
||||||
return ClaimTakeover, voidstar.(*ClaimTakeoverValue).PackValue(), nil
|
return voidstar.(*ClaimTakeoverValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case ClaimTakeover | 4<<8:
|
case ClaimTakeover | 4<<8:
|
||||||
return ClaimTakeover, ClaimTakeoverKeyPackPartialKey(voidstar.(*ClaimTakeoverKey)), nil
|
return ClaimTakeoverKeyPackPartialKey(voidstar.(*ClaimTakeoverKey)), nil
|
||||||
|
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.
|
|||||||
case PendingActivation:
|
case PendingActivation:
|
||||||
return PendingActivation, PendingActivationKeyUnpack(data), nil
|
return PendingActivationKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case PendingActivation | 1<<8:
|
case PendingActivation | 1<<8:
|
||||||
return PendingActivation, PendingActivationValueUnpack(data), nil
|
return PendingActivationValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case PendingActivation | 2<<8:
|
case PendingActivation | 2<<8:
|
||||||
return PendingActivation, voidstar.(*PendingActivationKey).PackKey(), nil
|
return voidstar.(*PendingActivationKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case PendingActivation | 3<<8:
|
case PendingActivation | 3<<8:
|
||||||
return PendingActivation, voidstar.(*PendingActivationValue).PackValue(), nil
|
return voidstar.(*PendingActivationValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case PendingActivation | 4<<8:
|
case PendingActivation | 4<<8:
|
||||||
return PendingActivation, PendingActivationKeyPackPartialKey(voidstar.(*PendingActivationKey)), nil
|
return PendingActivationKeyPackPartialKey(voidstar.(*PendingActivationKey)), nil
|
||||||
|
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.
|
|||||||
case ActivatedClaimAndSupport:
|
case ActivatedClaimAndSupport:
|
||||||
return ActivatedClaimAndSupport, ActivationKeyUnpack(data), nil
|
return ActivationKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ActivatedClaimAndSupport | 1<<8:
|
case ActivatedClaimAndSupport | 1<<8:
|
||||||
return ActivatedClaimAndSupport, ActivationValueUnpack(data), nil
|
return ActivationValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ActivatedClaimAndSupport | 2<<8:
|
case ActivatedClaimAndSupport | 2<<8:
|
||||||
return ActivatedClaimAndSupport, voidstar.(*ActivationKey).PackKey(), nil
|
return voidstar.(*ActivationKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case ActivatedClaimAndSupport | 3<<8:
|
case ActivatedClaimAndSupport | 3<<8:
|
||||||
return ActivatedClaimAndSupport, voidstar.(*ActivationValue).PackValue(), nil
|
return voidstar.(*ActivationValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case ActivatedClaimAndSupport | 4<<8:
|
case ActivatedClaimAndSupport | 4<<8:
|
||||||
return ActivatedClaimAndSupport, ActivationKeyPackPartialKey(voidstar.(*ActivationKey)), nil
|
return ActivationKeyPackPartialKey(voidstar.(*ActivationKey)), nil
|
||||||
|
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.
|
|||||||
case ActiveAmount:
|
case ActiveAmount:
|
||||||
return ActiveAmount, ActiveAmountKeyUnpack(data), nil
|
return ActiveAmountKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ActiveAmount | 1<<8:
|
case ActiveAmount | 1<<8:
|
||||||
return ActiveAmount, ActiveAmountValueUnpack(data), nil
|
return ActiveAmountValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ActiveAmount | 2<<8:
|
case ActiveAmount | 2<<8:
|
||||||
return ActiveAmount, voidstar.(*ActiveAmountKey).PackKey(), nil
|
return voidstar.(*ActiveAmountKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case ActiveAmount | 3<<8:
|
case ActiveAmount | 3<<8:
|
||||||
return ActiveAmount, voidstar.(*ActiveAmountValue).PackValue(), nil
|
return voidstar.(*ActiveAmountValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case ActiveAmount | 4<<8:
|
case ActiveAmount | 4<<8:
|
||||||
return ActiveAmount, ActiveAmountKeyPackPartialKey(voidstar.(*ActiveAmountKey)), nil
|
return ActiveAmountKeyPackPartialKey(voidstar.(*ActiveAmountKey)), nil
|
||||||
|
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.
|
|||||||
|
|
||||||
case Repost:
|
case Repost:
|
||||||
return Repost, RepostKeyUnpack(data), nil
|
return RepostKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case Repost | 1<<8:
|
case Repost | 1<<8:
|
||||||
return Repost, RepostValueUnpack(data), nil
|
return RepostValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case Repost | 2<<8:
|
case Repost | 2<<8:
|
||||||
return Repost, voidstar.(*RepostKey).PackKey(), nil
|
return voidstar.(*RepostKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case Repost | 3<<8:
|
case Repost | 3<<8:
|
||||||
return Repost, voidstar.(*RepostValue).PackValue(), nil
|
return voidstar.(*RepostValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case Repost | 4<<8:
|
case Repost | 4<<8:
|
||||||
return Repost, RepostKeyPackPartialKey(voidstar.(*RepostKey)), nil
|
return RepostKeyPackPartialKey(voidstar.(*RepostKey)), nil
|
||||||
|
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.
|
|||||||
case RepostedClaim:
|
case RepostedClaim:
|
||||||
return RepostedClaim, RepostedKeyUnpack(data), nil
|
return RepostedKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case RepostedClaim | 1<<8:
|
case RepostedClaim | 1<<8:
|
||||||
return RepostedClaim, RepostedValueUnpack(data), nil
|
return RepostedValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case RepostedClaim | 2<<8:
|
case RepostedClaim | 2<<8:
|
||||||
return RepostedClaim, voidstar.(*RepostedKey).PackKey(), nil
|
return voidstar.(*RepostedKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case RepostedClaim | 3<<8:
|
case RepostedClaim | 3<<8:
|
||||||
return RepostedClaim, voidstar.(*RepostedValue).PackValue(), nil
|
return voidstar.(*RepostedValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case RepostedClaim | 4<<8:
|
case RepostedClaim | 4<<8:
|
||||||
return RepostedClaim, RepostedKeyPackPartialKey(voidstar.(*RepostedKey)), nil
|
return RepostedKeyPackPartialKey(voidstar.(*RepostedKey)), nil
|
||||||
|
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.
|
|||||||
|
|
||||||
case Undo:
|
case Undo:
|
||||||
return Undo, UndoKeyUnpack(data), nil
|
return UndoKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case Undo | 1<<8:
|
case Undo | 1<<8:
|
||||||
return Undo, UndoValueUnpack(data), nil
|
return UndoValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case Undo | 2<<8:
|
case Undo | 2<<8:
|
||||||
return Undo, voidstar.(*UndoKey).PackKey(), nil
|
return voidstar.(*UndoKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case Undo | 3<<8:
|
case Undo | 3<<8:
|
||||||
return Undo, voidstar.(*UndoValue).PackValue(), nil
|
return voidstar.(*UndoValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case Undo | 4<<8:
|
case Undo | 4<<8:
|
||||||
return Undo, UndoKeyPackPartialKey(voidstar.(*UndoKey)), nil
|
return UndoKeyPackPartialKey(voidstar.(*UndoKey)), nil
|
||||||
|
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.
|
|||||||
case ClaimDiff:
|
case ClaimDiff:
|
||||||
return ClaimDiff, TouchedOrDeletedClaimKeyUnpack(data), nil
|
return TouchedOrDeletedClaimKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ClaimDiff | 1<<8:
|
case ClaimDiff | 1<<8:
|
||||||
return ClaimDiff, TouchedOrDeletedClaimValueUnpack(data), nil
|
return TouchedOrDeletedClaimValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ClaimDiff | 2<<8:
|
case ClaimDiff | 2<<8:
|
||||||
return ClaimDiff, voidstar.(*TouchedOrDeletedClaimKey).PackKey(), nil
|
return voidstar.(*TouchedOrDeletedClaimKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case ClaimDiff | 3<<8:
|
case ClaimDiff | 3<<8:
|
||||||
return ClaimDiff, voidstar.(*TouchedOrDeletedClaimValue).PackValue(), nil
|
return voidstar.(*TouchedOrDeletedClaimValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case ClaimDiff | 4<<8:
|
case ClaimDiff | 4<<8:
|
||||||
return ClaimDiff, TouchedOrDeletedClaimKeyPackPartialKey(voidstar.(*TouchedOrDeletedClaimKey)), nil
|
return TouchedOrDeletedClaimKeyPackPartialKey(voidstar.(*TouchedOrDeletedClaimKey)), nil
|
||||||
|
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.
|
|||||||
|
|
||||||
case Tx:
|
case Tx:
|
||||||
return Tx, TxKeyUnpack(data), nil
|
return TxKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case Tx | 1<<8:
|
case Tx | 1<<8:
|
||||||
return Tx, TxValueUnpack(data), nil
|
return TxValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case Tx | 2<<8:
|
case Tx | 2<<8:
|
||||||
return Tx, voidstar.(*TxKey).PackKey(), nil
|
return voidstar.(*TxKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case Tx | 3<<8:
|
case Tx | 3<<8:
|
||||||
return Tx, voidstar.(*TxValue).PackValue(), nil
|
return voidstar.(*TxValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case Tx | 4<<8:
|
case Tx | 4<<8:
|
||||||
return Tx, TxKeyPackPartialKey(voidstar.(*TxKey)), nil
|
return TxKeyPackPartialKey(voidstar.(*TxKey)), nil
|
||||||
|
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.
|
|||||||
case BlockHash:
|
case BlockHash:
|
||||||
return BlockHash, BlockHashKeyUnpack(data), nil
|
return BlockHashKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case BlockHash | 1<<8:
|
case BlockHash | 1<<8:
|
||||||
return BlockHash, BlockHashValueUnpack(data), nil
|
return BlockHashValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case BlockHash | 2<<8:
|
case BlockHash | 2<<8:
|
||||||
return BlockHash, voidstar.(*BlockHashKey).PackKey(), nil
|
return voidstar.(*BlockHashKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case BlockHash | 3<<8:
|
case BlockHash | 3<<8:
|
||||||
return BlockHash, voidstar.(*BlockHashValue).PackValue(), nil
|
return voidstar.(*BlockHashValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case BlockHash | 4<<8:
|
case BlockHash | 4<<8:
|
||||||
return BlockHash, BlockHashKeyPackPartialKey(voidstar.(*BlockHashKey)), nil
|
return BlockHashKeyPackPartialKey(voidstar.(*BlockHashKey)), nil
|
||||||
|
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.
|
|||||||
case Header:
|
case Header:
|
||||||
return Header, BlockHeaderKeyUnpack(data), nil
|
return BlockHeaderKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case Header | 1<<8:
|
case Header | 1<<8:
|
||||||
return Header, BlockHeaderValueUnpack(data), nil
|
return BlockHeaderValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case Header | 2<<8:
|
case Header | 2<<8:
|
||||||
return Header, voidstar.(*BlockHeaderKey).PackKey(), nil
|
return voidstar.(*BlockHeaderKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case Header | 3<<8:
|
case Header | 3<<8:
|
||||||
return Header, voidstar.(*BlockHeaderValue).PackValue(), nil
|
return voidstar.(*BlockHeaderValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case Header | 4<<8:
|
case Header | 4<<8:
|
||||||
return Header, BlockHeaderKeyPackPartialKey(voidstar.(*BlockHeaderKey)), nil
|
return BlockHeaderKeyPackPartialKey(voidstar.(*BlockHeaderKey)), nil
|
||||||
|
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.
|
|||||||
case TxNum:
|
case TxNum:
|
||||||
return TxNum, TxNumKeyUnpack(data), nil
|
return TxNumKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case TxNum | 1<<8:
|
case TxNum | 1<<8:
|
||||||
return TxNum, TxNumValueUnpack(data), nil
|
return TxNumValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case TxNum | 2<<8:
|
case TxNum | 2<<8:
|
||||||
return TxNum, voidstar.(*TxNumKey).PackKey(), nil
|
return voidstar.(*TxNumKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case TxNum | 3<<8:
|
case TxNum | 3<<8:
|
||||||
return TxNum, voidstar.(*TxNumValue).PackValue(), nil
|
return voidstar.(*TxNumValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case TxNum | 4<<8:
|
case TxNum | 4<<8:
|
||||||
return TxNum, TxNumKeyPackPartialKey(voidstar.(*TxNumKey)), nil
|
return TxNumKeyPackPartialKey(voidstar.(*TxNumKey)), nil
|
||||||
|
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.
|
|||||||
|
|
||||||
case TxCount:
|
case TxCount:
|
||||||
return TxCount, TxCountKeyUnpack(data), nil
|
return TxCountKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case TxCount | 1<<8:
|
case TxCount | 1<<8:
|
||||||
return TxCount, TxCountValueUnpack(data), nil
|
return TxCountValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case TxCount | 2<<8:
|
case TxCount | 2<<8:
|
||||||
return TxCount, voidstar.(*TxCountKey).PackKey(), nil
|
return voidstar.(*TxCountKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case TxCount | 3<<8:
|
case TxCount | 3<<8:
|
||||||
return TxCount, voidstar.(*TxCountValue).PackValue(), nil
|
return voidstar.(*TxCountValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case TxCount | 4<<8:
|
case TxCount | 4<<8:
|
||||||
return TxCount, TxCountKeyPackPartialKey(voidstar.(*TxCountKey)), nil
|
return TxCountKeyPackPartialKey(voidstar.(*TxCountKey)), nil
|
||||||
|
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.
|
|||||||
case TxHash:
|
case TxHash:
|
||||||
return TxHash, TxHashKeyUnpack(data), nil
|
return TxHashKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case TxHash | 1<<8:
|
case TxHash | 1<<8:
|
||||||
return TxHash, TxHashValueUnpack(data), nil
|
return TxHashValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case TxHash | 2<<8:
|
case TxHash | 2<<8:
|
||||||
return TxHash, voidstar.(*TxHashKey).PackKey(), nil
|
return voidstar.(*TxHashKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case TxHash | 3<<8:
|
case TxHash | 3<<8:
|
||||||
return TxHash, voidstar.(*TxHashValue).PackValue(), nil
|
return voidstar.(*TxHashValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case TxHash | 4<<8:
|
case TxHash | 4<<8:
|
||||||
return TxHash, TxHashKeyPackPartialKey(voidstar.(*TxHashKey)), nil
|
return TxHashKeyPackPartialKey(voidstar.(*TxHashKey)), nil
|
||||||
|
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.
|
|||||||
case UTXO:
|
case UTXO:
|
||||||
return UTXO, UTXOKeyUnpack(data), nil
|
return UTXOKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case UTXO | 1<<8:
|
case UTXO | 1<<8:
|
||||||
return UTXO, UTXOValueUnpack(data), nil
|
return UTXOValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case UTXO | 2<<8:
|
case UTXO | 2<<8:
|
||||||
return UTXO, voidstar.(*UTXOKey).PackKey(), nil
|
return voidstar.(*UTXOKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case UTXO | 3<<8:
|
case UTXO | 3<<8:
|
||||||
return UTXO, voidstar.(*UTXOValue).PackValue(), nil
|
return voidstar.(*UTXOValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case UTXO | 4<<8:
|
case UTXO | 4<<8:
|
||||||
return UTXO, UTXOKeyPackPartialKey(voidstar.(*UTXOKey)), nil
|
return UTXOKeyPackPartialKey(voidstar.(*UTXOKey)), nil
|
||||||
|
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.
|
|||||||
case HashXUTXO:
|
case HashXUTXO:
|
||||||
return UTXO, HashXUTXOKeyUnpack(data), nil
|
return HashXUTXOKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case HashXUTXO | 1<<8:
|
case HashXUTXO | 1<<8:
|
||||||
return UTXO, HashXUTXOValueUnpack(data), nil
|
return HashXUTXOValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case HashXUTXO | 2<<8:
|
case HashXUTXO | 2<<8:
|
||||||
return UTXO, voidstar.(*HashXUTXOKey).PackKey(), nil
|
return voidstar.(*HashXUTXOKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case HashXUTXO | 3<<8:
|
case HashXUTXO | 3<<8:
|
||||||
return UTXO, voidstar.(*HashXUTXOValue).PackValue(), nil
|
return voidstar.(*HashXUTXOValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case HashXUTXO | 4<<8:
|
case HashXUTXO | 4<<8:
|
||||||
return UTXO, HashXUTXOKeyPackPartialKey(voidstar.(*HashXUTXOKey)), nil
|
return HashXUTXOKeyPackPartialKey(voidstar.(*HashXUTXOKey)), nil
|
||||||
|
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.
|
|||||||
case HashXHistory:
|
case HashXHistory:
|
||||||
return HashXHistory, HashXHistoryKeyUnpack(data), nil
|
return HashXHistoryKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case HashXHistory | 1<<8:
|
case HashXHistory | 1<<8:
|
||||||
return HashXHistory, HashXHistoryValueUnpack(data), nil
|
return HashXHistoryValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case HashXHistory | 2<<8:
|
case HashXHistory | 2<<8:
|
||||||
return HashXHistory, voidstar.(*HashXHistoryKey).PackKey(), nil
|
return voidstar.(*HashXHistoryKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case HashXHistory | 3<<8:
|
case HashXHistory | 3<<8:
|
||||||
return HashXHistory, voidstar.(*HashXHistoryValue).PackValue(), nil
|
return voidstar.(*HashXHistoryValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case HashXHistory | 4<<8:
|
case HashXHistory | 4<<8:
|
||||||
return HashXHistory, HashXHistoryKeyPackPartialKey(voidstar.(*HashXHistoryKey)), nil
|
return HashXHistoryKeyPackPartialKey(voidstar.(*HashXHistoryKey)), nil
|
||||||
|
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.
|
|||||||
case DBState:
|
case DBState:
|
||||||
return DBState, DBStateKeyUnpack(data), nil
|
return DBStateKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case DBState | 1<<8:
|
case DBState | 1<<8:
|
||||||
return DBState, DBStateValueUnpack(data), nil
|
return DBStateValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case DBState | 2<<8:
|
case DBState | 2<<8:
|
||||||
return DBState, voidstar.(*DBStateKey).PackKey(), nil
|
return voidstar.(*DBStateKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case DBState | 3<<8:
|
case DBState | 3<<8:
|
||||||
return DBState, voidstar.(*DBStateValue).PackValue(), nil
|
return voidstar.(*DBStateValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case DBState | 4<<8:
|
case DBState | 4<<8:
|
||||||
return DBState, DBStateKeyPackPartialKey(voidstar.(*DBStateKey)), nil
|
return DBStateKeyPackPartialKey(voidstar.(*DBStateKey)), nil
|
||||||
|
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.
|
|||||||
|
|
||||||
case ChannelCount:
|
case ChannelCount:
|
||||||
return ChannelCount, ChannelCountKeyUnpack(data), nil
|
return ChannelCountKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ChannelCount | 1<<8:
|
case ChannelCount | 1<<8:
|
||||||
return ChannelCount, ChannelCountValueUnpack(data), nil
|
return ChannelCountValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case ChannelCount | 2<<8:
|
case ChannelCount | 2<<8:
|
||||||
return ChannelCount, voidstar.(*ChannelCountKey).PackKey(), nil
|
return voidstar.(*ChannelCountKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case ChannelCount | 3<<8:
|
case ChannelCount | 3<<8:
|
||||||
return ChannelCount, voidstar.(*ChannelCountValue).PackValue(), nil
|
return voidstar.(*ChannelCountValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case ChannelCount | 4<<8:
|
case ChannelCount | 4<<8:
|
||||||
return ChannelCount, ChannelCountKeyPackPartialKey(voidstar.(*ChannelCountKey)), nil
|
return ChannelCountKeyPackPartialKey(voidstar.(*ChannelCountKey)), nil
|
||||||
|
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.
|
|||||||
case SupportAmount:
|
case SupportAmount:
|
||||||
return SupportAmount, SupportAmountKeyUnpack(data), nil
|
return SupportAmountKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case SupportAmount | 1<<8:
|
case SupportAmount | 1<<8:
|
||||||
return SupportAmount, SupportAmountValueUnpack(data), nil
|
return SupportAmountValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case SupportAmount | 2<<8:
|
case SupportAmount | 2<<8:
|
||||||
return SupportAmount, voidstar.(*SupportAmountKey).PackKey(), nil
|
return voidstar.(*SupportAmountKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case SupportAmount | 3<<8:
|
case SupportAmount | 3<<8:
|
||||||
return SupportAmount, voidstar.(*SupportAmountValue).PackValue(), nil
|
return voidstar.(*SupportAmountValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case SupportAmount | 4<<8:
|
case SupportAmount | 4<<8:
|
||||||
return SupportAmount, SupportAmountKeyPackPartialKey(voidstar.(*SupportAmountKey)), nil
|
return SupportAmountKeyPackPartialKey(voidstar.(*SupportAmountKey)), nil
|
||||||
|
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.
|
|||||||
case BlockTXs:
|
case BlockTXs:
|
||||||
return BlockTXs, BlockTxsKeyUnpack(data), nil
|
return BlockTxsKeyUnpack(data), nil
|
||||||
|
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.
|
|||||||
case BlockTXs | 1<<8:
|
case BlockTXs | 1<<8:
|
||||||
return BlockTXs, BlockTxsValueUnpack(data), nil
|
return BlockTxsValueUnpack(data), nil
|
||||||
|
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.
|
|||||||
case BlockTXs | 2<<8:
|
case BlockTXs | 2<<8:
|
||||||
return BlockTXs, voidstar.(*BlockTxsKey).PackKey(), nil
|
return voidstar.(*BlockTxsKey).PackKey(), nil
|
||||||
|
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.
|
|||||||
case BlockTXs | 3<<8:
|
case BlockTXs | 3<<8:
|
||||||
return BlockTXs, voidstar.(*BlockTxsValue).PackValue(), nil
|
return voidstar.(*BlockTxsValue).PackValue(), nil
|
||||||
|
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.
|
|||||||
case BlockTXs | 4<<8:
|
case BlockTXs | 4<<8:
|
||||||
return BlockTXs, BlockTxsKeyPackPartialKey(voidstar.(*BlockTxsKey)), nil
|
return BlockTxsKeyPackPartialKey(voidstar.(*BlockTxsKey)), nil
|
||||||
|
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.
|
|||||||
|
|
||||||
}
|
}
|
||||||
return 0x0, nil, errors.Base("%s function for %v not implemented", functionName, firstByte)
|
return nil, errors.Base("%s function for %v not implemented", functionName, firstByte)
|
||||||
|
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 UnpackGenericKey(key []byte) (byte, interface{}, error) {
|
func UnpackGenericKey(key []byte) (interface{}, error) {
|
||||||
|
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 len(key) == 0 {
|
if len(key) == 0 {
|
||||||
return 0x0, nil, errors.Base("key length zero")
|
return nil, errors.Base("key length zero")
|
||||||
|
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.
|
|||||||
}
|
}
|
||||||
return generic(key, key[0], 0, "unpack key")
|
return generic(key, key[0], 0, "unpack key")
|
||||||
}
|
}
|
||||||
|
|
||||||
func UnpackGenericValue(key, value []byte) (byte, interface{}, error) {
|
func UnpackGenericValue(key, value []byte) (interface{}, error) {
|
||||||
|
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 len(key) == 0 {
|
if len(key) == 0 {
|
||||||
return 0x0, nil, errors.Base("key length zero")
|
return nil, errors.Base("key length zero")
|
||||||
|
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 len(value) == 0 {
|
if len(value) == 0 {
|
||||||
return 0x0, nil, errors.Base("value length zero")
|
return nil, errors.Base("value length zero")
|
||||||
|
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.
|
|||||||
}
|
}
|
||||||
return generic(value, key[0], 1, "unpack value")
|
return generic(value, key[0], 1, "unpack value")
|
||||||
}
|
}
|
||||||
|
|
||||||
func PackPartialGenericKey(prefix byte, key interface{}, nFields int) (byte, []byte, error) {
|
func PackPartialGenericKey(prefix byte, key interface{}, nFields int) ([]byte, error) {
|
||||||
|
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 key == nil {
|
if key == nil {
|
||||||
return 0x0, nil, errors.Base("key length zero")
|
return nil, errors.Base("key length zero")
|
||||||
|
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.
|
|||||||
}
|
}
|
||||||
x, y, z := generic(key, prefix, 4, "pack partial key")
|
genericRes, err := generic(key, prefix, 4, "pack partial key")
|
||||||
|
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.
|
|||||||
res := y.(func(int) []byte)(nFields)
|
res := genericRes.(func(int) []byte)(nFields)
|
||||||
|
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.
|
|||||||
return x, res, z
|
return res, err
|
||||||
|
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 PackGenericKey(prefix byte, key interface{}) (byte, []byte, error) {
|
func PackGenericKey(prefix byte, key interface{}) ([]byte, error) {
|
||||||
|
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 key == nil {
|
if key == nil {
|
||||||
return 0x0, nil, errors.Base("key length zero")
|
return nil, errors.Base("key length zero")
|
||||||
|
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.
|
|||||||
}
|
}
|
||||||
x, y, z := generic(key, prefix, 2, "pack key")
|
genericRes, err := generic(key, prefix, 2, "pack key")
|
||||||
|
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.
|
|||||||
return x, y.([]byte), z
|
return genericRes.([]byte), err
|
||||||
|
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 PackGenericValue(prefix byte, value interface{}) (byte, []byte, error) {
|
func PackGenericValue(prefix byte, value interface{}) ([]byte, error) {
|
||||||
|
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 value == nil {
|
if value == nil {
|
||||||
return 0x0, nil, errors.Base("value length zero")
|
return nil, errors.Base("value length zero")
|
||||||
|
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.
|
|||||||
}
|
}
|
||||||
x, y, z := generic(value, prefix, 3, "pack value")
|
genericRes, err := generic(value, prefix, 3, "pack value")
|
||||||
|
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.
|
|||||||
return x, y.([]byte), z
|
return genericRes.([]byte), err
|
||||||
|
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.
|
|||||||
|
|
@ -10,7 +10,7 @@ import (
|
||||||
"testing"
|
"testing"
|
||||||
|
|
||||||
dbpkg "github.com/lbryio/hub/db"
|
dbpkg "github.com/lbryio/hub/db"
|
||||||
"github.com/lbryio/hub/db/prefixes"
|
prefixes "github.com/lbryio/hub/db/prefixes"
|
||||||
"github.com/linxGnu/grocksdb"
|
"github.com/linxGnu/grocksdb"
|
||||||
)
|
)
|
||||||
|
|
||||||
|
|
@ -67,20 +67,20 @@ func testGeneric(filePath string, prefix byte, numPartials int) func(*testing.T)
|
||||||
var i = 0
|
var i = 0
|
||||||
for kv := range ch {
|
for kv := range ch {
|
||||||
// log.Println(kv.Key)
|
// log.Println(kv.Key)
|
||||||
_, gotKey, err := prefixes.PackGenericKey(prefix, kv.Key)
|
gotKey, err := prefixes.PackGenericKey(prefix, kv.Key)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
log.Println(err)
|
log.Println(err)
|
||||||
}
|
}
|
||||||
|
|
||||||
for j := 1; j <= numPartials; j++ {
|
for j := 1; j <= numPartials; j++ {
|
||||||
_, keyPartial, _ := prefixes.PackPartialGenericKey(prefix, kv.Key, j)
|
keyPartial, _ := prefixes.PackPartialGenericKey(prefix, kv.Key, j)
|
||||||
// Check pack partial for sanity
|
// Check pack partial for sanity
|
||||||
if !bytes.HasPrefix(gotKey, keyPartial) {
|
if !bytes.HasPrefix(gotKey, keyPartial) {
|
||||||
t.Errorf("%+v should be prefix of %+v\n", keyPartial, gotKey)
|
t.Errorf("%+v should be prefix of %+v\n", keyPartial, gotKey)
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
_, got, err := prefixes.PackGenericValue(prefix, kv.Value)
|
got, err := prefixes.PackGenericValue(prefix, kv.Value)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
log.Println(err)
|
log.Println(err)
|
||||||
}
|
}
|
||||||
|
|
@ -119,7 +119,7 @@ func testGeneric(filePath string, prefix byte, numPartials int) func(*testing.T)
|
||||||
ch2 := dbpkg.Iter(db, options2)
|
ch2 := dbpkg.Iter(db, options2)
|
||||||
i = 0
|
i = 0
|
||||||
for kv := range ch2 {
|
for kv := range ch2 {
|
||||||
_, got, err := prefixes.PackGenericValue(prefix, kv.Value)
|
got, err := prefixes.PackGenericValue(prefix, kv.Value)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
log.Println(err)
|
log.Println(err)
|
||||||
}
|
}
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
package server
|
package server_test
|
||||||
|
|
||||||
import (
|
import (
|
||||||
"bufio"
|
"bufio"
|
||||||
|
|
@ -12,6 +12,7 @@ import (
|
||||||
|
|
||||||
"github.com/lbryio/hub/internal/metrics"
|
"github.com/lbryio/hub/internal/metrics"
|
||||||
pb "github.com/lbryio/hub/protobuf/go"
|
pb "github.com/lbryio/hub/protobuf/go"
|
||||||
|
server "github.com/lbryio/hub/server"
|
||||||
dto "github.com/prometheus/client_model/go"
|
dto "github.com/prometheus/client_model/go"
|
||||||
"google.golang.org/grpc"
|
"google.golang.org/grpc"
|
||||||
)
|
)
|
||||||
|
|
@ -43,19 +44,19 @@ func removeFile(fileName string) {
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
func makeDefaultArgs() *Args {
|
func makeDefaultArgs() *server.Args {
|
||||||
args := &Args{
|
args := &server.Args{
|
||||||
CmdType: ServeCmd,
|
CmdType: server.ServeCmd,
|
||||||
Host: DefaultHost,
|
Host: server.DefaultHost,
|
||||||
Port: DefaultPort,
|
Port: server.DefaultPort,
|
||||||
EsHost: DefaultEsHost,
|
EsHost: server.DefaultEsHost,
|
||||||
EsPort: DefaultEsPort,
|
EsPort: server.DefaultEsPort,
|
||||||
PrometheusPort: DefaultPrometheusPort,
|
PrometheusPort: server.DefaultPrometheusPort,
|
||||||
EsIndex: DefaultEsIndex,
|
EsIndex: server.DefaultEsIndex,
|
||||||
RefreshDelta: DefaultRefreshDelta,
|
RefreshDelta: server.DefaultRefreshDelta,
|
||||||
CacheTTL: DefaultCacheTTL,
|
CacheTTL: server.DefaultCacheTTL,
|
||||||
PeerFile: DefaultPeerFile,
|
PeerFile: server.DefaultPeerFile,
|
||||||
Country: DefaultCountry,
|
Country: server.DefaultCountry,
|
||||||
DisableEs: true,
|
DisableEs: true,
|
||||||
Debug: true,
|
Debug: true,
|
||||||
DisableLoadPeers: true,
|
DisableLoadPeers: true,
|
||||||
|
|
@ -88,26 +89,26 @@ func TestAddPeer(t *testing.T) {
|
||||||
|
|
||||||
for _, tt := range tests {
|
for _, tt := range tests {
|
||||||
t.Run(tt.name, func(t *testing.T) {
|
t.Run(tt.name, func(t *testing.T) {
|
||||||
server := MakeHubServer(ctx, args)
|
hubServer := server.MakeHubServer(ctx, args)
|
||||||
server.ExternalIP = net.IPv4(0, 0, 0, 0)
|
hubServer.ExternalIP = net.IPv4(0, 0, 0, 0)
|
||||||
metrics.PeersKnown.Set(0)
|
metrics.PeersKnown.Set(0)
|
||||||
|
|
||||||
for i := 0; i < 10; i++ {
|
for i := 0; i < 10; i++ {
|
||||||
var peer *Peer
|
var peer *server.Peer
|
||||||
if strings.Contains(tt.name, "1 unique") {
|
if strings.Contains(tt.name, "1 unique") {
|
||||||
peer = &Peer{
|
peer = &server.Peer{
|
||||||
Address: "1.1.1.1",
|
Address: "1.1.1.1",
|
||||||
Port: "50051",
|
Port: "50051",
|
||||||
}
|
}
|
||||||
} else {
|
} else {
|
||||||
x := i + 1
|
x := i + 1
|
||||||
peer = &Peer{
|
peer = &server.Peer{
|
||||||
Address: fmt.Sprintf("%d.%d.%d.%d", x, x, x, x),
|
Address: fmt.Sprintf("%d.%d.%d.%d", x, x, x, x),
|
||||||
Port: "50051",
|
Port: "50051",
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
//log.Printf("Adding peer %+v\n", msg)
|
//log.Printf("Adding peer %+v\n", msg)
|
||||||
err := server.addPeer(peer, false, false)
|
err := hubServer.AddPeerExported()(peer, false, false)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
log.Println(err)
|
log.Println(err)
|
||||||
}
|
}
|
||||||
|
|
@ -147,31 +148,31 @@ func TestPeerWriter(t *testing.T) {
|
||||||
|
|
||||||
for _, tt := range tests {
|
for _, tt := range tests {
|
||||||
t.Run(tt.name, func(t *testing.T) {
|
t.Run(tt.name, func(t *testing.T) {
|
||||||
server := MakeHubServer(ctx, args)
|
hubServer := server.MakeHubServer(ctx, args)
|
||||||
server.ExternalIP = net.IPv4(0, 0, 0, 0)
|
hubServer.ExternalIP = net.IPv4(0, 0, 0, 0)
|
||||||
|
|
||||||
for i := 0; i < 10; i++ {
|
for i := 0; i < 10; i++ {
|
||||||
var peer *Peer
|
var peer *server.Peer
|
||||||
if strings.Contains(tt.name, "1 unique") {
|
if strings.Contains(tt.name, "1 unique") {
|
||||||
peer = &Peer{
|
peer = &server.Peer{
|
||||||
Address: "1.1.1.1",
|
Address: "1.1.1.1",
|
||||||
Port: "50051",
|
Port: "50051",
|
||||||
}
|
}
|
||||||
} else {
|
} else {
|
||||||
x := i + 1
|
x := i + 1
|
||||||
peer = &Peer{
|
peer = &server.Peer{
|
||||||
Address: fmt.Sprintf("%d.%d.%d.%d", x, x, x, x),
|
Address: fmt.Sprintf("%d.%d.%d.%d", x, x, x, x),
|
||||||
Port: "50051",
|
Port: "50051",
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
//log.Printf("Adding peer %+v\n", peer)
|
//log.Printf("Adding peer %+v\n", peer)
|
||||||
err := server.addPeer(peer, false, false)
|
err := hubServer.AddPeerExported()(peer, false, false)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
log.Println(err)
|
log.Println(err)
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
//log.Println("Counting lines...")
|
//log.Println("Counting lines...")
|
||||||
got := lineCountFile(server.Args.PeerFile)
|
got := lineCountFile(hubServer.Args.PeerFile)
|
||||||
if got != tt.want {
|
if got != tt.want {
|
||||||
t.Errorf("lineCountFile(peers.txt) = %d, want %d", got, tt.want)
|
t.Errorf("lineCountFile(peers.txt) = %d, want %d", got, tt.want)
|
||||||
}
|
}
|
||||||
|
|
@ -211,12 +212,12 @@ func TestAddPeerEndpoint(t *testing.T) {
|
||||||
|
|
||||||
for _, tt := range tests {
|
for _, tt := range tests {
|
||||||
t.Run(tt.name, func(t *testing.T) {
|
t.Run(tt.name, func(t *testing.T) {
|
||||||
server := MakeHubServer(ctx, args)
|
hubServer := server.MakeHubServer(ctx, args)
|
||||||
server2 := MakeHubServer(ctx, args2)
|
hubServer2 := server.MakeHubServer(ctx, args2)
|
||||||
metrics.PeersKnown.Set(0)
|
metrics.PeersKnown.Set(0)
|
||||||
go server.Run()
|
go hubServer.Run()
|
||||||
go server2.Run()
|
go hubServer2.Run()
|
||||||
//go server.Run()
|
//go hubServer.Run()
|
||||||
conn, err := grpc.Dial("localhost:"+args.Port,
|
conn, err := grpc.Dial("localhost:"+args.Port,
|
||||||
grpc.WithInsecure(),
|
grpc.WithInsecure(),
|
||||||
grpc.WithBlock(),
|
grpc.WithBlock(),
|
||||||
|
|
@ -237,15 +238,15 @@ func TestAddPeerEndpoint(t *testing.T) {
|
||||||
log.Println(err)
|
log.Println(err)
|
||||||
}
|
}
|
||||||
|
|
||||||
server.GrpcServer.GracefulStop()
|
hubServer.GrpcServer.GracefulStop()
|
||||||
server2.GrpcServer.GracefulStop()
|
hubServer2.GrpcServer.GracefulStop()
|
||||||
got1 := server.getNumPeers()
|
got1 := hubServer.GetNumPeersExported()()
|
||||||
got2 := server2.getNumPeers()
|
got2 := hubServer2.GetNumPeersExported()()
|
||||||
if got1 != tt.wantServerOne {
|
if got1 != tt.wantServerOne {
|
||||||
t.Errorf("len(server.PeerServers) = %d, want %d\n", got1, tt.wantServerOne)
|
t.Errorf("len(hubServer.PeerServers) = %d, want %d\n", got1, tt.wantServerOne)
|
||||||
}
|
}
|
||||||
if got2 != tt.wantServerTwo {
|
if got2 != tt.wantServerTwo {
|
||||||
t.Errorf("len(server2.PeerServers) = %d, want %d\n", got2, tt.wantServerTwo)
|
t.Errorf("len(hubServer2.PeerServers) = %d, want %d\n", got2, tt.wantServerTwo)
|
||||||
}
|
}
|
||||||
})
|
})
|
||||||
}
|
}
|
||||||
|
|
@ -277,13 +278,13 @@ func TestAddPeerEndpoint2(t *testing.T) {
|
||||||
|
|
||||||
for _, tt := range tests {
|
for _, tt := range tests {
|
||||||
t.Run(tt.name, func(t *testing.T) {
|
t.Run(tt.name, func(t *testing.T) {
|
||||||
server := MakeHubServer(ctx, args)
|
hubServer := server.MakeHubServer(ctx, args)
|
||||||
server2 := MakeHubServer(ctx, args2)
|
hubServer2 := server.MakeHubServer(ctx, args2)
|
||||||
server3 := MakeHubServer(ctx, args3)
|
hubServer3 := server.MakeHubServer(ctx, args3)
|
||||||
metrics.PeersKnown.Set(0)
|
metrics.PeersKnown.Set(0)
|
||||||
go server.Run()
|
go hubServer.Run()
|
||||||
go server2.Run()
|
go hubServer2.Run()
|
||||||
go server3.Run()
|
go hubServer3.Run()
|
||||||
conn, err := grpc.Dial("localhost:"+args.Port,
|
conn, err := grpc.Dial("localhost:"+args.Port,
|
||||||
grpc.WithInsecure(),
|
grpc.WithInsecure(),
|
||||||
grpc.WithBlock(),
|
grpc.WithBlock(),
|
||||||
|
|
@ -313,20 +314,20 @@ func TestAddPeerEndpoint2(t *testing.T) {
|
||||||
log.Println(err)
|
log.Println(err)
|
||||||
}
|
}
|
||||||
|
|
||||||
server.GrpcServer.GracefulStop()
|
hubServer.GrpcServer.GracefulStop()
|
||||||
server2.GrpcServer.GracefulStop()
|
hubServer2.GrpcServer.GracefulStop()
|
||||||
server3.GrpcServer.GracefulStop()
|
hubServer3.GrpcServer.GracefulStop()
|
||||||
got1 := server.getNumPeers()
|
got1 := hubServer.GetNumPeersExported()()
|
||||||
got2 := server2.getNumPeers()
|
got2 := hubServer2.GetNumPeersExported()()
|
||||||
got3 := server3.getNumPeers()
|
got3 := hubServer3.GetNumPeersExported()()
|
||||||
if got1 != tt.wantServerOne {
|
if got1 != tt.wantServerOne {
|
||||||
t.Errorf("len(server.PeerServers) = %d, want %d\n", got1, tt.wantServerOne)
|
t.Errorf("len(hubServer.PeerServers) = %d, want %d\n", got1, tt.wantServerOne)
|
||||||
}
|
}
|
||||||
if got2 != tt.wantServerTwo {
|
if got2 != tt.wantServerTwo {
|
||||||
t.Errorf("len(server2.PeerServers) = %d, want %d\n", got2, tt.wantServerTwo)
|
t.Errorf("len(hubServer2.PeerServers) = %d, want %d\n", got2, tt.wantServerTwo)
|
||||||
}
|
}
|
||||||
if got3 != tt.wantServerThree {
|
if got3 != tt.wantServerThree {
|
||||||
t.Errorf("len(server3.PeerServers) = %d, want %d\n", got3, tt.wantServerThree)
|
t.Errorf("len(hubServer3.PeerServers) = %d, want %d\n", got3, tt.wantServerThree)
|
||||||
}
|
}
|
||||||
})
|
})
|
||||||
}
|
}
|
||||||
|
|
@ -358,13 +359,13 @@ func TestAddPeerEndpoint3(t *testing.T) {
|
||||||
|
|
||||||
for _, tt := range tests {
|
for _, tt := range tests {
|
||||||
t.Run(tt.name, func(t *testing.T) {
|
t.Run(tt.name, func(t *testing.T) {
|
||||||
server := MakeHubServer(ctx, args)
|
hubServer := server.MakeHubServer(ctx, args)
|
||||||
server2 := MakeHubServer(ctx, args2)
|
hubServer2 := server.MakeHubServer(ctx, args2)
|
||||||
server3 := MakeHubServer(ctx, args3)
|
hubServer3 := server.MakeHubServer(ctx, args3)
|
||||||
metrics.PeersKnown.Set(0)
|
metrics.PeersKnown.Set(0)
|
||||||
go server.Run()
|
go hubServer.Run()
|
||||||
go server2.Run()
|
go hubServer2.Run()
|
||||||
go server3.Run()
|
go hubServer3.Run()
|
||||||
conn, err := grpc.Dial("localhost:"+args.Port,
|
conn, err := grpc.Dial("localhost:"+args.Port,
|
||||||
grpc.WithInsecure(),
|
grpc.WithInsecure(),
|
||||||
grpc.WithBlock(),
|
grpc.WithBlock(),
|
||||||
|
|
@ -402,20 +403,20 @@ func TestAddPeerEndpoint3(t *testing.T) {
|
||||||
log.Println(err)
|
log.Println(err)
|
||||||
}
|
}
|
||||||
|
|
||||||
server.GrpcServer.GracefulStop()
|
hubServer.GrpcServer.GracefulStop()
|
||||||
server2.GrpcServer.GracefulStop()
|
hubServer2.GrpcServer.GracefulStop()
|
||||||
server3.GrpcServer.GracefulStop()
|
hubServer3.GrpcServer.GracefulStop()
|
||||||
got1 := server.getNumPeers()
|
got1 := hubServer.GetNumPeersExported()()
|
||||||
got2 := server2.getNumPeers()
|
got2 := hubServer2.GetNumPeersExported()()
|
||||||
got3 := server3.getNumPeers()
|
got3 := hubServer3.GetNumPeersExported()()
|
||||||
if got1 != tt.wantServerOne {
|
if got1 != tt.wantServerOne {
|
||||||
t.Errorf("len(server.PeerServers) = %d, want %d\n", got1, tt.wantServerOne)
|
t.Errorf("len(hubServer.PeerServers) = %d, want %d\n", got1, tt.wantServerOne)
|
||||||
}
|
}
|
||||||
if got2 != tt.wantServerTwo {
|
if got2 != tt.wantServerTwo {
|
||||||
t.Errorf("len(server2.PeerServers) = %d, want %d\n", got2, tt.wantServerTwo)
|
t.Errorf("len(hubServer2.PeerServers) = %d, want %d\n", got2, tt.wantServerTwo)
|
||||||
}
|
}
|
||||||
if got3 != tt.wantServerThree {
|
if got3 != tt.wantServerThree {
|
||||||
t.Errorf("len(server3.PeerServers) = %d, want %d\n", got3, tt.wantServerThree)
|
t.Errorf("len(hubServer3.PeerServers) = %d, want %d\n", got3, tt.wantServerThree)
|
||||||
}
|
}
|
||||||
})
|
})
|
||||||
}
|
}
|
||||||
|
|
@ -436,41 +437,41 @@ func TestUDPServer(t *testing.T) {
|
||||||
want string
|
want string
|
||||||
}{
|
}{
|
||||||
{
|
{
|
||||||
name: "hubs server external ip",
|
name: "hubs hubServer external ip",
|
||||||
want: "127.0.0.1",
|
want: "127.0.0.1",
|
||||||
},
|
},
|
||||||
}
|
}
|
||||||
|
|
||||||
for _, tt := range tests {
|
for _, tt := range tests {
|
||||||
t.Run(tt.name, func(t *testing.T) {
|
t.Run(tt.name, func(t *testing.T) {
|
||||||
server := MakeHubServer(ctx, args)
|
hubServer := server.MakeHubServer(ctx, args)
|
||||||
server2 := MakeHubServer(ctx, args2)
|
hubServer2 := server.MakeHubServer(ctx, args2)
|
||||||
go server.Run()
|
go hubServer.Run()
|
||||||
go server2.Run()
|
go hubServer2.Run()
|
||||||
metrics.PeersKnown.Set(0)
|
metrics.PeersKnown.Set(0)
|
||||||
|
|
||||||
peer := &Peer{
|
peer := &server.Peer{
|
||||||
Address: "0.0.0.0",
|
Address: "0.0.0.0",
|
||||||
Port: "50052",
|
Port: "50052",
|
||||||
}
|
}
|
||||||
|
|
||||||
err := server.addPeer(peer, true, true)
|
err := hubServer.AddPeerExported()(peer, true, true)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
log.Println(err)
|
log.Println(err)
|
||||||
}
|
}
|
||||||
|
|
||||||
server.GrpcServer.GracefulStop()
|
hubServer.GrpcServer.GracefulStop()
|
||||||
server2.GrpcServer.GracefulStop()
|
hubServer2.GrpcServer.GracefulStop()
|
||||||
|
|
||||||
got1 := server.ExternalIP.String()
|
got1 := hubServer.ExternalIP.String()
|
||||||
if got1 != tt.want {
|
if got1 != tt.want {
|
||||||
t.Errorf("server.ExternalIP = %s, want %s\n", got1, tt.want)
|
t.Errorf("hubServer.ExternalIP = %s, want %s\n", got1, tt.want)
|
||||||
t.Errorf("server.Args.Port = %s\n", server.Args.Port)
|
t.Errorf("hubServer.Args.Port = %s\n", hubServer.Args.Port)
|
||||||
}
|
}
|
||||||
got2 := server2.ExternalIP.String()
|
got2 := hubServer2.ExternalIP.String()
|
||||||
if got2 != tt.want {
|
if got2 != tt.want {
|
||||||
t.Errorf("server2.ExternalIP = %s, want %s\n", got2, tt.want)
|
t.Errorf("hubServer2.ExternalIP = %s, want %s\n", got2, tt.want)
|
||||||
t.Errorf("server2.Args.Port = %s\n", server2.Args.Port)
|
t.Errorf("hubServer2.Args.Port = %s\n", hubServer2.Args.Port)
|
||||||
}
|
}
|
||||||
})
|
})
|
||||||
}
|
}
|
||||||
|
|
|
||||||
69
server/search_test.go
Normal file
|
|
@ -0,0 +1,69 @@
|
||||||
|
package server_test
|
||||||
|
|
||||||
|
import (
|
||||||
|
"context"
|
||||||
|
"fmt"
|
||||||
|
"log"
|
||||||
|
"net/http"
|
||||||
|
"net/http/httptest"
|
||||||
|
"strings"
|
||||||
|
"testing"
|
||||||
|
|
||||||
|
pb "github.com/lbryio/hub/protobuf/go"
|
||||||
|
server "github.com/lbryio/hub/server"
|
||||||
|
"github.com/olivere/elastic/v7"
|
||||||
|
)
|
||||||
|
|
||||||
|
func TestInt32ArrToInterface(t *testing.T) {
|
||||||
|
want := []int32{0, 10, 100}
|
||||||
|
got := server.Int32ArrToInterface(want)
|
||||||
|
for i, x := range got {
|
||||||
|
if x.(int32) != want[i] {
|
||||||
|
t.Errorf("flags: got: %v, want: %v\n", x, want[i])
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
func TestStrArrToInterface(t *testing.T) {
|
||||||
|
want := []string{"asdf", "qwer", "xczv"}
|
||||||
|
got := server.StrArrToInterface(want)
|
||||||
|
for i, x := range got {
|
||||||
|
if strings.Compare(x.(string), want[i]) != 0 {
|
||||||
|
t.Errorf("flags: got: %v, want: %v\n", x, want[i])
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
func TestAddTermsField(t *testing.T) {
|
||||||
|
name := "qwer"
|
||||||
|
arr := []string{"a", "b", "c"}
|
||||||
|
var query *elastic.BoolQuery = elastic.NewBoolQuery()
|
||||||
|
query = server.AddTermsField(query, arr, name)
|
||||||
|
fmt.Printf("query: %v\n", query)
|
||||||
|
}
|
||||||
|
|
||||||
|
func TestSearch(t *testing.T) {
|
||||||
|
handler := http.NotFound
|
||||||
|
ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
|
||||||
|
handler(w, r)
|
||||||
|
}))
|
||||||
|
defer ts.Close()
|
||||||
|
|
||||||
|
handler = func(w http.ResponseWriter, r *http.Request) {
|
||||||
|
resp := `{}`
|
||||||
|
|
||||||
|
w.Write([]byte(resp))
|
||||||
|
}
|
||||||
|
|
||||||
|
context := context.Background()
|
||||||
|
args := makeDefaultArgs()
|
||||||
|
hubServer := server.MakeHubServer(context, args)
|
||||||
|
req := &pb.SearchRequest{
|
||||||
|
Text: "asdf",
|
||||||
|
}
|
||||||
|
out, err := hubServer.Search(context, req)
|
||||||
|
if err != nil {
|
||||||
|
log.Println(err)
|
||||||
|
}
|
||||||
|
log.Println(out)
|
||||||
|
}
|
||||||
9
server/server_test_pkg.go
Normal file
|
|
@ -0,0 +1,9 @@
|
||||||
|
package server
|
||||||
|
|
||||||
|
func (s *Server) AddPeerExported() func(*Peer, bool, bool) error {
|
||||||
|
return s.addPeer
|
||||||
|
}
|
||||||
|
|
||||||
|
func (s *Server) GetNumPeersExported() func() int64 {
|
||||||
|
return s.getNumPeers
|
||||||
|
}
|
||||||
|
|
@ -1,10 +1,12 @@
|
||||||
package server
|
package server_test
|
||||||
|
|
||||||
import (
|
import (
|
||||||
"log"
|
"log"
|
||||||
"os/exec"
|
"os/exec"
|
||||||
"strings"
|
"strings"
|
||||||
"testing"
|
"testing"
|
||||||
|
|
||||||
|
server "github.com/lbryio/hub/server"
|
||||||
)
|
)
|
||||||
|
|
||||||
// TestUDPPing tests UDPPing correctness against prod server.
|
// TestUDPPing tests UDPPing correctness against prod server.
|
||||||
|
|
@ -36,7 +38,7 @@ func TestUDPPing(t *testing.T) {
|
||||||
toAddr := "spv16.lbry.com"
|
toAddr := "spv16.lbry.com"
|
||||||
toPort := "50001"
|
toPort := "50001"
|
||||||
|
|
||||||
pong, err := UDPPing(toAddr, toPort)
|
pong, err := server.UDPPing(toAddr, toPort)
|
||||||
gotCountry := pong.DecodeCountry()
|
gotCountry := pong.DecodeCountry()
|
||||||
if err != nil {
|
if err != nil {
|
||||||
log.Println(err)
|
log.Println(err)
|
||||||
|
|
|
||||||
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
👀