Documentation
¶
Overview ¶
Package codegen generates ip2x source code for IP2Location binary databases.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Main ¶
func Main()
Main should be called from the main function of a standalone Go program containing Product and Field consts to generate the code for ip2x.
The first time, you will need to run `go run thisfilename.go` manually, but afterwards, you can use `go generate` to update it.
Example:
//go:build ignore
package main
import "internal/codegen"
//go:generate go run thisfilename.go
func main() {
codegen.Main()
}
Types ¶
type Field ¶ added in v0.2.2
type Field string
Field defines an IP2Location binary database column.
The value should be the IP2Location database column name, as used in Product.
The documentation comment should follow standard godoc syntax.
Note that the enum values exported by the package depend on the order these fields are defined. If ip2x is being used as intended, this shouldn't make a difference since these numbers are not exposed or stored, but to maintain strict ABI compatibility, fields should not be reordered or removed. If one must be removed while preserving numbering, you can define a dummy field like `const _ codegen.Field = ""` to skip a value.
Example:
// Two-character country code based on ISO 3166. const CountryCode codegen.Field = `country_code` // Country name based on ISO 3166. const CountryCode codegen.Field = `country_name` // OldField contains some information. // // Deprecated: No longer included in any currently supported products. Use // [Special1] instead. const OldField codegen.Field = "old_field" // Some useful info. // // See https://example.com for more information. const Special1 codegen.Field = "special1" // Some values: // - (VALUE1) one thing // - (VALUE2) another thing const Special2 codegen.Field = "special2" // Even more information. const Special3 codegen.Field = "special3"
type Product ¶
type Product string
Product defines an IP2Location binary database product.
The first line should be the internal database product code, followed by the product type prefix (e.g., DB or PX), then the human-readable product name, then a sequential series of numbers starting at 1, with one for each product type (i.e., variant).
The following lines define the columns in the file. First, it should specify the field type (currently str/f32, plus an optional @N suffix for pointers where N is the number of bytes to add to the uint32 offset in the database before reading it). This should be followed by the column name (which must have a corresponding [Column] defined), then the database column number for each database type (starting at 2 since column 1 is always ip_from, and . if it is not present in the database type).
The documentation comment should follow standard godoc syntax.
The values will be checked to ensure they are valid, for example by:
- Ensuring database types are sequential uint8s starting at 1.
- Ensuring each database type's columns are sequential uint8s starting at 2, and each is only used for a single type or type+ptr+offset.
- Ensuring type names are valid.
- Ensuring the product code is a valid uint8, with only one product defined for each product code.
- Ensuring each column name is defined by [Column] and only used once in the product.
Example:
// ProductName™ is a fake example which provides solutions to all your // problems. const ProductName codegen.Product = ` 1 ProductName PN 1 2 3 4 5 str@0 country_code 2 2 2 2 2 str@3 country_name 2 2 2 2 2 str@0 old_field 3 . . . . str@0 special1 . 3 3 . 5 str@0 special2 . . 4 3 3 f32 special3 . . . 4 4 `
Source Files