rocksdb #29
16
db/db.go
|
|
@ -173,6 +173,7 @@ func UnpackGenericValue(key, value []byte) (byte, interface{}, error) {
|
|||
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator 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 NewIterateOptions() *IterOptions {
|
||||
return &IterOptions{
|
||||
FillCache: false,
|
||||
Prefix: []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.
|
||||
Start: nil,
|
||||
Stop: nil,
|
||||
IncludeStart: true,
|
||||
|
|
@ -189,6 +190,11 @@ func (o *IterOptions) WithFillCache(fillCache 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
|
||||
}
|
||||
|
||||
func (o *IterOptions) WithPrefix(prefix []byte) *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.
|
||||
o.Prefix = 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.
|
||||
return o
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator 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 (o *IterOptions) WithStart(start []byte) *IterOptions {
|
||||
o.Start = start
|
||||
return o
|
||||
|
|
@ -219,6 +225,16 @@ func (o *IterOptions) WithIncludeValue(includeValue 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
|
||||
}
|
||||
|
||||
func (o *IterOptions) WithRawKey(rawKey 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.
|
||||
o.RawKey = rawKey
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator 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
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator 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 (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.
|
||||
o.RawValue = rawValue
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator 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
|
||||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator 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 (k *UTXOKey) String() string {
|
||||
return fmt.Sprintf(
|
||||
"%s(hashX=%s, tx_num=%d, nout=%d)",
|
||||
|
|
|
|||
|
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
no need to start these with N no need to start these with N
and many of these are unused and many of these are unused
is this really no big deal? seems like an error to me but idk rocksdb is this really no big deal? seems like an error to me but idk rocksdb
typo: Famlies -> Families typo: Famlies -> Families
this can be unexported this can be unexported
still need this? still need this?
typo typo
👀 :eyes:
I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation. I agree the "N" can go. I copied these all over from the Python. where I believe they are similarly unused, because I thought it might be the defacto documentation.
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this. ```
// Valid returns false only when an Iterator has iterated past either the
// first or the last key in the database.
func (iter *Iterator) Valid() bool {
return C.rocksdb_iter_valid(iter.c) != 0
}
```
If our iterator was to try to go off the end of the db, or the front if we're going backwards, we need to check this.
|
||||
|
|
@ -1,45 +1,6 @@
|
|||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as 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.
|
||||
package prefixes
|
||||
|
||||
const (
|
||||
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//ClaimToSupport = []byte("K")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//SupportToClaim = []byte("L")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//ClaimToTXO = []byte("E")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//TXOToClaim = []byte("G")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as 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.
|
||||
//ClaimToChannel = []byte("I")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//ChannelToClaim = []byte("J")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as 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.
|
||||
//ClaimShortIdPrefix = []byte("F")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//EffectiveAmount = []byte("D")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//ClaimExpiration = []byte("O")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as 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.
|
||||
//ClaimTakeover = []byte("P")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//PendingActivation = []byte("Q")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//ActivatedClaimAndSupport = []byte("R")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//ActiveAmount = []byte("S")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as 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.
|
||||
//Repost = []byte("V")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//RepostedClaim = []byte("W")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as 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.
|
||||
//Undo = []byte("M")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//ClaimDiff = []byte("Y")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as 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.
|
||||
//Tx = []byte("B")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//BlockHash = []byte("C")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//Header = []byte("H")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//TxNum = []byte("N")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//TxCount = []byte("T")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//TxHash = []byte("X")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//UTXO = []byte("u")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//HashXUTXO = []byte("h")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//HashXHistory = []byte("x")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//DBState = []byte("s")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//ChannelCount = []byte("Z")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//SupportAmount = []byte("a")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
//BlockTXs = []byte("b")
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as 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.
|
||||
ClaimToSupport = 'K'
|
||||
SupportToClaim = 'L'
|
||||
|
||||
|
|
@ -53,10 +14,10 @@ const (
|
|||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as 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.
|
||||
EffectiveAmount = 'D'
|
||||
ClaimExpiration = 'O'
|
||||
|
||||
ActiveAmount = 'S'
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
ClaimTakeover = 'P'
|
||||
PendingActivation = 'Q'
|
||||
ActivatedClaimAndSupport = 'R'
|
||||
ActiveAmount = 'S'
|
||||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address.
|
||||
|
||||
Repost = 'V'
|
||||
RepostedClaim = 'W'
|
||||
|
|
|
|||
|
why snake case here? why snake case here?
if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25 if this is a fixed size, should it be an array? or even a chainhash.Hash? https://github.com/lbryio/lbcd/blob/master/chaincfg/chainhash/hash.go#L25
i suggest using lbcd types as much as possible where it makes sense. if something is a Hash, make it a Hash. if its an Address, make it an Address. i suggest using lbcd types as 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.
|
||||
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
👀