Skip to content
This repository has been archived by the owner on Sep 7, 2021. It is now read-only.
This repository is currently being migrated. It's locked while the migration is in progress.

Add default postgres schema so that it can be changed #824

Merged
merged 1 commit into from
Jan 9, 2018

Conversation

lunny
Copy link
Member

@lunny lunny commented Jan 9, 2018

No description provided.

@lunny lunny added this to the 0.7 milestone Jan 9, 2018
@lunny
Copy link
Member Author

lunny commented Jan 9, 2018

will be a basis to resolve go-gitea/gitea#2755

@appleboy
Copy link
Member

appleboy commented Jan 9, 2018

examples:

func init() {
	xorm.DefaultPostgresSchema = "mcs"
}

// NewEngine initializes a new xorm.Engine
func NewEngine() (err error) {
	if err = SetEngine(); err != nil {
		return err
	}

	if err = x.Ping(); err != nil {
		return err
	}

	row, err := x.Exec(`SELECT schema_name FROM information_schema.schemata WHERE schema_name = 'mcs';`)
	if err != nil {
		return err
	}

	affects, err := row.RowsAffected()
	if affects == 0 {
		if _, err = x.Exec(`CREATE SCHEMA "mcs"`); err != nil {
			return err
		}
	}

	if _, err = x.Exec(`SET SEARCH_PATH = mcs, pg_catalog`); err != nil {
		return err
	}

	m := migrate.New(x, migrate.DefaultOptions, migrations)
	if err = m.Migrate(); err != nil {
		return fmt.Errorf("migrate: %v", err)
	}

	if err = x.StoreEngine("InnoDB").Sync2(tables...); err != nil {
		return fmt.Errorf("sync database struct error: %v", err)
	}

	return nil
}

@codecov-io
Copy link

Codecov Report

Merging #824 into master will increase coverage by 0.02%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #824      +/-   ##
==========================================
+ Coverage    53.2%   53.22%   +0.02%     
==========================================
  Files          39       39              
  Lines        7323     7324       +1     
==========================================
+ Hits         3896     3898       +2     
  Misses       2931     2931              
+ Partials      496      495       -1
Impacted Files Coverage Δ
dialect_postgres.go 77.85% <100%> (+0.08%) ⬆️
xorm.go 68.33% <0%> (+1.66%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5275c0d...1eb2b49. Read the comment docs.

@lunny lunny merged commit 5185fdf into master Jan 9, 2018
@lunny lunny deleted the lunny/add_default_postgres_schema branch January 9, 2018 09:08
marefr added a commit to grafana/grafana that referenced this pull request May 29, 2019
xorm introduced some changes in
go-xorm/xorm#824 and
go-xorm/xorm#876 which by default will use
public as the postgres schema and this was a breaking change compared
to before. Grafana has implemented a custom postgres dialect so above
changes wasn't a problem here. However, Grafana's custom database
migration was using xorm dialect to check if the migration table exists
or not.
For those using a custom search_path (schema) in postgres configured on
server, database or user level the migration table check would not find
the migration table since it was looking in public schema due to xorm
changes above. This had the consequence that Grafana's database
migration failed the second time since migration had already run
migrations in another schema.
This change will make xorm use an empty default schema for postgres and
by that mimic the functionality of how it was functioning before
xorm's changes above.
marefr added a commit to grafana/grafana that referenced this pull request Jun 3, 2019
xorm introduced some changes in
go-xorm/xorm#824 and
go-xorm/xorm#876 which by default will use
public as the postgres schema and this was a breaking change compared
to before. Grafana has implemented a custom postgres dialect so above
changes wasn't a problem here. However, Grafana's custom database
migration was using xorm dialect to check if the migration table exists
or not.
For those using a custom search_path (schema) in postgres configured on
server, database or user level the migration table check would not find
the migration table since it was looking in public schema due to xorm
changes above. This had the consequence that Grafana's database
migration failed the second time since migration had already run
migrations in another schema.
This change will make xorm use an empty default schema for postgres and
by that mimic the functionality of how it was functioning before
xorm's changes above.
Fixes #16720

Co-Authored-By: Carl Bergquist <carl@grafana.com>
aocenas pushed a commit to grafana/grafana that referenced this pull request Jun 5, 2019
xorm introduced some changes in
go-xorm/xorm#824 and
go-xorm/xorm#876 which by default will use
public as the postgres schema and this was a breaking change compared
to before. Grafana has implemented a custom postgres dialect so above
changes wasn't a problem here. However, Grafana's custom database
migration was using xorm dialect to check if the migration table exists
or not.
For those using a custom search_path (schema) in postgres configured on
server, database or user level the migration table check would not find
the migration table since it was looking in public schema due to xorm
changes above. This had the consequence that Grafana's database
migration failed the second time since migration had already run
migrations in another schema.
This change will make xorm use an empty default schema for postgres and
by that mimic the functionality of how it was functioning before
xorm's changes above.
Fixes #16720

Co-Authored-By: Carl Bergquist <carl@grafana.com>
(cherry picked from commit b7a9533)
aocenas pushed a commit to grafana/grafana that referenced this pull request Jun 5, 2019
xorm introduced some changes in
go-xorm/xorm#824 and
go-xorm/xorm#876 which by default will use
public as the postgres schema and this was a breaking change compared
to before. Grafana has implemented a custom postgres dialect so above
changes wasn't a problem here. However, Grafana's custom database
migration was using xorm dialect to check if the migration table exists
or not.
For those using a custom search_path (schema) in postgres configured on
server, database or user level the migration table check would not find
the migration table since it was looking in public schema due to xorm
changes above. This had the consequence that Grafana's database
migration failed the second time since migration had already run
migrations in another schema.
This change will make xorm use an empty default schema for postgres and
by that mimic the functionality of how it was functioning before
xorm's changes above.
Fixes #16720

Co-Authored-By: Carl Bergquist <carl@grafana.com>
(cherry picked from commit b7a9533)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants