Web-based, zero-config, dependency-free database schema change and version control tool for teams

Bytebase

Live DemoInstallHelpDevelopmentDesign Doc

license status go report Docker pulls

Bytebase is a web-based, zero-config, dependency-free database schema change and version control management tool for developers and DBAs.

  • Web-based schema change and management workspace for teams
  • Version control based schema migration (Database-as-Code)
  • Classic UI based schema migraiton (SQL Review)
  • Detailed migration history
  • Backup and restore
  • Anomaly center
  • Environment policy
    • Approval policy
    • Backup schedule enforcement
  • Schema drift detection
  • Backward compatibility schema change check
  • Role-based access control (RBAC)
  • MySQL support
  • PostgreSQL support
  • TiDB support
  • Snowflake support
  • ClickHouse support
  • GitLab CE/EE support
  • Webhook integration for Slack, Discord, MS Teams, DingTalk(钉钉), Feishu(飞书), WeCom(企业微信)
  • GitLab.com support
  • GitHub support
Fig.1 - Dashboard

Screenshot

Fig.2 - SQL review issue pipeline

Screenshot

Fig.3 - GitLab based schema migration (Database-as-code)

Screenshot

Installation

Detailed installation guide

Run on localhost:8080

docker run --init --name bytebase --restart always --publish 8080:8080 --volume ~/.bytebase/data:/var/opt/bytebase bytebase/bytebase:0.9.0 --data /var/opt/bytebase --host http://localhost --port 8080

Run on https://bytebase.example.com

docker run --init --name bytebase --restart always --publish 80:80 --volume ~/.bytebase/data:/var/opt/bytebase bytebase/bytebase:0.9.0 --data /var/opt/bytebase --host https://bytebase.example.com --port 80

📕 Docs

User doc https://docs.bytebase.com

In particular, get familar with various product concept such as data model, roles and permissions and etc.

Design doc

https://github.com/bytebase/bytebase/tree/main/docs/design

🕊 Interested in contributing?

  1. Checkout issues tagged with good first issue.

  2. We are maintaining an online database glossary list, you can add/improve content there.

🏗 Development

Bytebase is built with a curated tech stack. It is optimized for developer experience and is very easy to start working on the code:

  1. It has no external dependency.
  2. It requires zero config.
  3. 1 command to start backend and 1 command to start frontend, both with live reload support.

Tech Stack

Screenshot

Data Model

Screenshot

Prerequisites

  • Go (1.16 or later)
  • Yarn
  • Air (For backend live reload)

Steps

  1. Install Air.

  2. Pull source.

    git clone https://github.com/bytebase/bytebase
  3. Set up pre-commit hooks.

     cd bytebase
     pre-commit install
     pre-commit install --hook-type commit-msg
  4. Start backend using air (with live reload).

    air -c scripts/.air.toml

    Change the open file limit if you encounter "error: too many open files".

    ulimit -n 10240
    
  5. Start frontend (with live reload).

    cd frontend && yarn && yarn dev

Bytebase should now be running at https://localhost:3000 and change either frontend or backend code would trigger live reload.

Coding guideline

Here

Notice

Bytebase is in public alpha and we may make breaking schema changes between versions. We plan to stabilize the schema around the middle of August. In the mean time, if you are eager to try Bytebase for your business and encounter issue when upgrading to the new version. Please contact [email protected] or join our Discord server, and we will help you manually upgrade the schema.

We are hiring

We are looking for an experienced frontend engineer to lead Bytebase frontend development. Check out our jobs page.

Owner
Bytebase
Web-based, zero-config, dependency-free database schema change and version control management tool for teams.
Bytebase
Comments
  • fix(ui/ux): pipeline flow nav item overflow

    fix(ui/ux): pipeline flow nav item overflow

    Before: Xnip2022-02-26_13-54-09

    After fix: image

    Fixed this layout problem only in PC viewport, it also appear in mobile view.

    See this.

    Xnip2022-02-26_14-07-43

    Unlike the previous ones, this is the tooltip element css position, and a solution can be negotiated.

  • fix: tenant mode VSC with DatebaseNameTemplate task execute error

    fix: tenant mode VSC with DatebaseNameTemplate task execute error

    Signed-off-by: cluas [email protected]

    case:

    • tenant template: {{DB_NAME}}_{{TENTANT}}
    • tenants: a, b
    • demo db: demo
    • file path template: {{DB_NAME}}__{{VERSION}}__{{TYPE}}__{{DESCRIPTION}}.sql
    • example push file: demo__v0.1.0__migrate__demo.sql
    • tasks after gitops webhook: task1 {database: demo_a, namespace: demo_a}}, task2 {database: demo_b, namespace: demo_b}}

    but here it parse {{DB_NAME}}, in this case, always is demo. so subsequent tasks will immediately go wrong.

  • Error status code 422 trying to integrate version control with project

    Error status code 422 trying to integrate version control with project

    Provide the MySQL version you are using (if related with instance/database operation) MariaDB 10.6.4

    Provide the Bytebase version you are using 0.8.1

    Describe the bug After adding a project, database, initial migration schema, and Git provider (self hosted gitlab instance), I attempted to integrate my project with Gitlab. At the final step where you click Finish it gives me an error message "Failed to create webhook for project ID: 101, status code: 422"

    Steps or screenshots to reproduce the behavior

    1. Go to project
    2. Click Version Control tab
    3. Click Version Control Workflow and click Configure version control button
    4. Click on existing Git provider
    5. Click on repo
    6. Enter "master" as the branch
    7. Click Finish
    8. See error: "Failed to create webhook for project ID: 101, status code: 422"

    Expected behavior

    Version control is integrated successfully.

    Desktop (please complete the following information):

    • Browser Firefox 91.3.0esr

    I'm not sure what to look for. I also tried unprotecting the master branch for the repo but I'm still seeing this error message. If it's relevant, I do not have any .sql files present in the repo yet as I'm not sure whether Bytebase is supposed to create them for me, or if I'm supposed to provide them ahead of time... I assumed Bytebase would generate the .sql files in the repo.

  • feat(PITR): embed mysqlbinlog

    feat(PITR): embed mysqlbinlog

    TODO:

    • [x] Embed mysqlbinlog-8.0.28-macos11-arm64
    • [x] Embed mysqlbinlog-8.0.28-linux-glibc-2.17-x86_64
    • [x] A tiny unit test for mysqlbinlog-8.0.28-linux-glibc-2.17-x86_64
    • [x] Describe production process
  • When docker run according to docs ERROR   failed to extract txz file, error: failed to create directory

    When docker run according to docs ERROR failed to extract txz file, error: failed to create directory "share/postgresql/", error: mkdir /var/opt/bytebase/resources: permission denied

    Provide the Bytebase version you are using docker 1.0.0 Describe the bug

    docker run --init --name bytebase --restart always --publish 80:80 --volume ~/.bytebase/data:/var/opt/bytebase bytebase/bytebase:1.0.0 --data /var/opt/bytebase --host https://bytebase.example.com --port 80
    -----Config BEGIN-----
    mode=release
    server=https://bytebase.example.com:80
    datastore=https://bytebase.example.com:81
    frontend=https://bytebase.example.com:80
    dsn=file:/var/opt/bytebase/bytebase.db
    resourceDir=/var/opt/bytebase/resources
    pgdataDir=/var/opt/bytebase/pgdata
    seedDir=seed/release
    readonly=false
    demo=false
    debug=false
    -----Config END-------
    2022-03-11 03:23:24.091208 I | Installing Postgres OS "linux" Arch "amd64" txz "postgres-linux-x86_64-alpine_linux.txz"
    2022-03-11T03:23:24.092Z        ERROR   failed to extract txz file, error: failed to create directory "share/postgresql/", error: mkdir /var/opt/bytebase/resources: permission denied
    
  • Schema update in VCS doesn't trigger Bytebase to apply the change

    Schema update in VCS doesn't trigger Bytebase to apply the change

    Provide the MySQL version you are using (if related with instance/database operation) MySQL 5.6.30

    Provide the GitLab version you are using (if related with VCS integration) 14.5.0

    Provide the Bytebase version you are using 0.8.1

    Describe the bug After integrating with self hosted Gitlab, I set the file path template and schema path template, then committed a schema update to the repository matching the template, but nothing happened in Bytebase. Even with debug logging enabled, I don't see any activity on Bytebase.

    Steps or screenshots to reproduce the behavior

    1. Integrate VCS with a project
    2. Set branch to master
    3. Set file path template to {{DB_NAME}}{{VERSION}}{{TYPE}}.sql
    4. Click Update button
    5. Commit a file in the root directory of the master branch named dbtest__202112031025__migrate.sql
    6. Expect something to happen in Bytebase but nothing happens
    7. Check the debug output, but there is nothing
    8. Confirm the instance name is dbtest
    9. Confirm the database name is dbtest

    Expected behavior

    I believe a new migration is supposed to happen in Bytebase, but I'm not sure if it's an issue where Gitlab is not calling Bytebase to do the update, or if Bytebase is not polling Gitlab for changes, or maybe it's not detecting a matching file pattern.

    Desktop (please complete the following information):

    • Browser Firefox 91.3.0esr

    Additional context

    It would be helpful if the documentation explained in a little more detail what the process was. For example, does Gitlab send a webhook reqeust to Bytebase after committing to the repo, or does Bytebase periodically check for changes in the repo? Also it would be helpful in the case where Bytebase checked for schema updates to log that it didn't find any files matching the pattern.

  • fix: send SIGINT to clean up resources

    fix: send SIGINT to clean up resources

    Send SIGINT to backend when restarting to make sure the sqlite database is closed properly.

    This PR is blocked by a PR for air.

    After this change, I start to see the "BYE" banner when I make a change: Screen Shot 2021-12-02 at 8 46 46 PM

  • Chrome all labels show as their variable names.

    Chrome all labels show as their variable names.

    Provide the Bytebase version you are using 1.0.3, I also tested 1.0.2 and 1.0.0

    Describe the bug

    When using Google Chrome all labels show as their variable names.

    Steps or screenshots to reproduce the behavior

    1. Startup Bytebase
    2. visit the dashboard
    Screenshot 2022-04-13 at 14 51 55

    Expected behavior

    As in example screenshots and safari. actual content & titles instead of variable namings. Screenshot 2022-04-13 at 15 08 47

    Desktop (please complete the following information):

    • Browser [chrome]
    • Version [100]

    Additional context

    • Update: It seems like a content management issue in chrome 100. A lot of content isn't displayed. e.g. Modal pop-ups have no content. only a variable name.
  • feat: move oauth token exchange logic to the backend

    feat: move oauth token exchange logic to the backend

    function effected:

    1. login via VCS both access token and application secret is invisible to the frontend
    2. set up a VCS for the workspace for the user need to set up the secret for the first time, no logic changed
    3. set up a VCS repo for the project application secret is invisible to the frontend, the access token will still return by the backend for we may still need the token to access VCS resource Possible improvement: store the gitlab token in the cookie just like how we store our access token
  • Introduce testify assertions for simplifying testing code

    Introduce testify assertions for simplifying testing code

    So far, bytebase adopt the bundled go testing framework to run unit test. It's good to follow and well integrated with the ecosystem.

    However, manually verify assertions and write error message handy is a bit awkward. Thus, I propose we introduce testify assertions for simplifying testing code.

    Before:

    func TestUnmarshal(t *testing.T) {
    	// ...
    	if err := jsonapi.UnmarshalPayload(bytes.NewReader(b), databasePatch); err != nil {
    		t.Fatal(err)
    	}
    
    	var labels []*DatabaseLabel
    	if err := json.Unmarshal([]byte(*databasePatch.Labels), &labels); err != nil {
    		t.Fatal(err)
    	}
    	for i, label := range labels {
    		if keys[i] != label.Key || values[i] != label.Value {
    			t.Fatal("Key value pair does not match!")
    		}
    	}
    }
    

    After:

    func TestUnmarshal(t *testing.T) {
    	// ...
    	require.NoError(t, jsonapi.UnmarshalPayload(bytes.NewReader(b), databasePatch))
    
    	var labels []*DatabaseLabel
    	require.NoError(t, json.Unmarshal([]byte(*databasePatch.Labels), &labels))
    	for i, label := range labels {
    		require.Equal(t, keys[i], label.Key)
    		require.Equal(t, values[i], label.Value)
    	}
    }
    

    What do you think?

    Notes

    Note that what I propose here is assertion of testify only, excluding its suite gear which share global state and somehow buggy.

    Also, I don't propose a series of works to globally migrate tests from one flavor to another. Since we're working well so far, I tend to regard such an introduction as supplements and best practice which we can gradually adopt. (Yes. The original motivation is when I debugging bytebase, I'd like to write testify assertions instead of manually asserting.)

    There may be some concerns that the last release of testify upstream was made more than one year ago. But I think the current functionality is good to use. Otherwise, we may write our own assertions but it's almost duplicate work of good enough open-source artifacts.

  • Timeout while adding existing Clickhouse instance, UI hangs

    Timeout while adding existing Clickhouse instance, UI hangs

    Clickhouse version: 21.11.1 revision 54450

    Provide the Bytebase version you are using 0.12.0 running in Docker

    Describe the bug

    While running a small setup locally for testing, Bytebase in Docker + 4-node cluster of Clickhouse in Docker. When clickhouse instance doesn't contain any objects or user DBs/tables, adding an instance works quick and as expected. However, once there are objects defined (10+ DBs, each containing a number of tables), no data, the 'add Instance' dialog window never finishes, keeps stuck on 'creating' phase:

    Screenshot 2022-01-27 at 11 34 05

    and after 20-30 seconds fails with an error message in the lower-right corner: Screenshot 2022-01-27 at 11 33 56

    After closing the window which never finishes, it looks like the databases are all get imported, so hitting some sort of a timeout in UI, but in a backend it seems to generally work.

    I presume it's related to Bytebase connecting to Clickhouse and taking some time to extract the schema definition, and hitting a timeout at some point.

    Steps or screenshots to reproduce the behavior

    1. Go to 'Instance' menu section
    2. Click on 'Add instance'
    3. Fill in details for a Clickhouse instance running in cluster configuration (maybe a single instance will do too?) containing a good number of objects.
    4. Clic on 'Create'.

    Expected behavior

    Instance 'Create' form window closing and reporting success.

    Desktop (please complete the following information):

    • Browser: Safari
    • Version 15.1
  • feat(frontend): PITR create issue

    feat(frontend): PITR create issue

    • [x] The [Restore] button only enabled when allowAdmin and doneBackupList.length > 0. "done" backup is a backup with backup.status === "DONE".
    • [x] The date-time picker will disable dates after today or before the earliest date of available backups.
    • [x] Call [POST] /api/issue endpoint to validate and create a PITR issue.
    • [x] isDev() guarded.
    • [ ] PITR optimized issue UI is not implemented yet. Falling back to standard mode UI. Will do this in future PRs.
    • [ ] Introduce a menu of something to "Restore" in the "Backup" panel, allowing the user to choose whether to restore the backup to a new database or use PITR.

    pitr-2

  • FindMigrationHistoryList error when use external pg

    FindMigrationHistoryList error when use external pg

    • use external pg as bytebase db
    • create db on tenant mode project check duplicate version error: "failed to connect to `host=xxx user=xxx database=bytebase`: server error (FATAL: database \"bytebase\" does not exist (SQLSTATE 3D000))"

    https://github.com/bytebase/bytebase/blob/5d3ca6e452bec01bc8362964c3c2b4698d04e782/plugin/db/util/driverutil.go#L191 https://github.com/bytebase/bytebase/blob/5d3ca6e452bec01bc8362964c3c2b4698d04e782/plugin/db/pg/pg.go#L1011

    I think it was these two places that caused this problem,the dsn of the target database is used instead of the dsn of the external pg

  • Existing PG extensions & views will block --pg perform metadb migration

    Existing PG extensions & views will block --pg perform metadb migration

    Provide the Bytebase version you are using

    v1.0.4

    Describe the bug

    Use external pg with existing schemas prevent bytebase perform metadb migration.

    The docker-compose.yaml conf file

    version: "3"
    services:
      bytebase:
        container_name: bytebase
        image: bytebase/bytebase:1.0.4
        restart: unless-stopped
        ports:
          - "8887:8887"
        command: |
          --host http://ddl.pigsty --port 8887 --data /var/opt/bytebase --pg postgres://dbuser_bytebase:[email protected]:5432/bytebase
    

    The error output:

    2022-05-04T03:22:18.808Z	INFO	Establishing external PostgreSQL connection...	{"pgURL": "postgres://dbuser_bytebase:[email protected]:5432/bytebase"}
    2022-05-04T03:22:18.833Z	INFO	Apply database migration if needed...
    2022-05-04T03:22:18.833Z	INFO	The database schema has not been setup.
    2022-05-04T03:22:18.834Z	INFO	The prod cutoff schema version: 1.0.1
    2022-05-04T03:22:18.859Z	ERROR	cannot open db: failed to migrate: failed to migrate initial schema version "migration/prod/LATEST.sql", error: failed to get views from database "bytebase": schema "repack" view "primary_keys" has empty definition; please check whether proper privileges have been granted to Bytebase
    2022-05-04T03:22:18.859Z	INFO	Trying to stop Bytebase...
    2022-05-04T03:22:18.859Z	INFO	Bytebase stopped properly.
    
    2022-05-04T03:24:28.132Z	INFO	Establishing external PostgreSQL connection...	{"pgURL": "postgres://dbuser_bytebase:[email protected]:5432/bytebase"}
    2022-05-04T03:24:28.153Z	INFO	Apply database migration if needed...
    2022-05-04T03:24:28.153Z	INFO	The database schema has not been setup.
    2022-05-04T03:24:28.153Z	INFO	The prod cutoff schema version: 1.0.1
    2022-05-04T03:24:28.178Z	ERROR	cannot open db: failed to migrate: failed to migrate initial schema version "migration/prod/LATEST.sql", error: failed to get views from database "bytebase": schema "monitor" view "pg_stat_statements_info" has empty definition; please check whether proper privileges have been granted to Bytebase
    2022-05-04T03:24:28.178Z	INFO	Trying to stop Bytebase...
    2022-05-04T03:24:28.178Z	INFO	Bytebase stopped properly.
    

    The database is already provisioned with extension pg_stat_statements under schema monitor and pg_repack extension under schema pg_repack.

    After drop extension pg_repack and drop pg_stat_statements, bytebase launch schema-migration successfully.

    Expected behavior

    Is there some introspection failure for views?

    ByteBase will ignore existing schema, or ignore view created by other extensions.

    Or at least add options to specify which schemas to be omitted.

  • docker restart bytebase report errors  error: database

    docker restart bytebase report errors error: database "bb" has already applied version 10001

    version bytebase/bytebase:1.0.1

    waiting for server to start....2022-04-01 05:41:23.521 UTC [15] LOG: starting PostgreSQL 14.2 on x86_64-pc-linux-musl, compiled by gcc (Alpine 6.3.0) 6.3.0, 64-bit 2022-04-01 05:41:23.521 UTC [15] LOG: listening on IPv4 address "127.0.0.1", port 5679 2022-04-01 05:41:23.521 UTC [15] LOG: could not bind IPv6 address "::1": Address not available 2022-04-01 05:41:23.523 UTC [15] LOG: listening on Unix socket "/tmp/.s.PGSQL.5679" 2022-04-01 05:41:23.525 UTC [16] LOG: database system was shut down at 2022-04-01 05:40:23 UTC 2022-04-01 05:41:23.528 UTC [15] LOG: database system is ready to accept connections done server started 2022-04-01T05:41:23.638Z INFO Apply database migration if needed... 2022-04-01T05:41:23.638Z INFO Current schema version before migration: 1.0 2022-04-01T05:41:23.638Z INFO Migrating migration/10001__init_schema.sql... 2022-04-01T05:41:23.994Z ERROR cannot open db: failed to migrate: failed to migrate schema version "10001__init_schema.sql", error: database "bb" has already applied version 10001 2022-04-01T05:41:23.994Z INFO Trying to stop Bytebase... 2022-04-01T05:41:23.994Z INFO Trying to shutdown postgresql server... 2022-04-01 05:41:23.995 UTC [15] LOG: received fast shutdown request 2022-04-01 05:41:23.996 UTC [15] LOG: aborting any active transactions 2022-04-01 05:41:23.996 UTC [32] FATAL: terminating connection due to administrator command 2022-04-01 05:41:23.996 UTC [15] LOG: background worker "logical replication launcher" (PID 22) exited with exit code 1 2022-04-01 05:41:23.997 UTC [17] LOG: shutting down 2022-04-01 05:41:24.007 UTC [15] LOG: database system is shut down waiting for server to shut down.... done server stopped 2022-04-01T05:41:24.095Z INFO Bytebase stopped properly.

  • ☂️ GitHub Git provider

    ☂️ GitHub Git provider

    Context

    This is a tracking issue for adding GitHub as a Git provider based on Bytebase GitHub Git provider design doc.

    Frontend and backend work can be parallelized, and the frontend uses IsDev() to guard changes until completion.

    TODO

    • [x] Make necessary changes to the database schema to allow the existence of GITHUB_COM as a value of VCS type.
    • [x] Implement the VCS provider workflow
      • [x] Implement the necessary methods of vcs.Provider interface for GitHub.com
      • [x] Audit call sites to the implemented methods of vcs.Provider and update places that are hard-coded for GitLabSelfHost to have code branches to handle GitHubCom.
      • [x] Implement necessary frontend changes.
    • [ ] Implement the project VCS setting
      • [ ] Implement the necessary methods of vcs.Provider interface for GitHub.com
        • Previously hard-coded repositoryID in method signatures is very GitLab-specific; the recommended alternative is externalID.
      • [ ] Audit call sites to the implemented methods of vcs.Provider and update places that are hard-coded for GitLabSelfHost to have code branches to handle GitHubCom.
      • [ ] Implement necessary frontend changes.
    • [ ] Add two POST endpoints to accept access token exchange (/api/github/exchangetoken and fetching repositories (/api/github/repository) requests for GitHub.
    • [ ] Implement GitHub webhook handler
    • [ ] Timebox: Support sign-in with GitHub.com
A flexible and powerful SQL string builder library plus a zero-config ORM.

SQL builder for Go Install Usage Basic usage Pre-defined SQL builders Build SQL for MySQL, PostgreSQL or SQLite Using Struct as a light weight ORM Nes

May 7, 2022
Zero boilerplate database operations for Go
Zero boilerplate database operations for Go

(Now compatible with MySQL and PostgreSQL!) Everyone knows that performing simple DATABASE queries in Go takes numerous lines of code that is often re

May 10, 2022
Podman based development-only dependency manager for Linux.

Tent is a CLI tool for running development dependencies such as MySQL, Mongo, ElasticSearch etc inside pre-configured containers using simple one

Mar 2, 2022
GitHub's Online Schema Migrations for MySQL
GitHub's Online Schema Migrations for MySQL

gh-ost GitHub's online schema migration for MySQL gh-ost is a triggerless online schema migration solution for MySQL. It is testable and provides paus

May 10, 2022
Manage Schema for KubeDB managed Databases

schema-manager Manage Schema for KubeDB managed Databases Installation To install KubeDB, please follow the guide here. Using KubeDB Want to learn how

Feb 19, 2022
Go library that stores data in Redis with SQL-like schema

Go library that stores data in Redis with SQL-like schema. The goal of this library is we can store data in Redis with table form.

Mar 14, 2022
Stash large datasets on GitHub for free, quick, and easy download 🐿

squirrel Stash large datasets on GitHub for free, quick, and easy download ?? Install To install squirrel, run the following: curl ... Usage Create a

Dec 31, 2021
[mirror] the database client and tools for the Go vulnerability database

The Go Vulnerability Database golang.org/x/vulndb This repository is a prototype of the Go Vulnerability Database. Read the Draft Design. Neither the

May 3, 2022
Database - Example project of database realization using drivers and models

database Golang based database realization Description Example project of databa

Feb 10, 2022
Package sqlite is a CGo-free port of SQLite.

sqlite Package sqlite is a CGo-free port of SQLite. SQLite is an in-process implementation of a self-contained, serverless, zero-configuration, transa

Nov 30, 2021
A simple Golang-based application that queries a PostgreSQL database

Qwik-E-Mart Demo App A simple Golang-based application that queries a PostgreSQL database named qwikemart to read and return customer data stored in t

Nov 6, 2021
🏋️ dbbench is a simple database benchmarking tool which supports several databases and own scripts

dbbench Table of Contents Description Example Installation Supported Databases Usage Custom Scripts Troubeshooting Development Acknowledgements Descri

May 9, 2022
Dumpling is a fast, easy-to-use tool written by Go for dumping data from the database(MySQL, TiDB...) to local/cloud(S3, GCP...) in multifarious formats(SQL, CSV...).

?? Dumpling Dumpling is a tool and a Go library for creating SQL dump from a MySQL-compatible database. It is intended to replace mysqldump and mydump

Apr 21, 2022
Goose database migration tool - fork of https://bitbucket.org/liamstask/goose

goose Goose is a database migration tool. Manage your database schema by creating incremental SQL changes or Go functions. Goals of this fork github.c

May 9, 2022
The EVEmu Database Tool

EVEDBTool - The EVEmu Database Tool This is a tool written in Go to manage the installation, versioning and update of the EVEmu database. A pre-built

Feb 9, 2022
A tool I made to quickly store bug bounty program scopes in a local sqlite3 database

GoScope A tool I made to quickly store bug bounty program scopes in a local sqlite3 database. Download or copy a Burpsuite configuration file from the

Nov 18, 2021
A database connection tool for sensitive data
A database connection tool for sensitive data

go-sql 用于快速统计数据库行数、敏感字段匹配、数据库连接情况。 usage ./go-sql_darwin_amd64 -h ./go-sql_darwin_amd64 -f db.yaml -k name,user ./go-sql_darwin_amd64 -f db.yaml --min

Apr 4, 2022
A Go rest API project that is following solid and common principles and is connected to local MySQL database.
A Go rest API project that is following solid and common principles and is connected to local MySQL database.

This is an intermediate-level go project that running with a project structure optimized RESTful API service in Go. API's of that project is designed based on solid and common principles and connected to the local MySQL database.

Apr 26, 2022