Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

Installing fresh openstreetmap database fails #4613

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 5 comments
Closed

Installing fresh openstreetmap database fails #4613

openstreetmap-trac opened this issue Jul 23, 2021 · 5 comments

Comments

@openstreetmap-trac
Copy link

Reporter: yurivict
[Submitted to the original trac issue database at 7.19am, Sunday, 7th October 2012]

Using PostgresSQL 9.2.1 on FreeBSD 9.1 amd64.

Command rake db:migrate always fails when it is run first, see log below. Second run though succeeds.

I am not an expert in PostgreSQL, but it seems strange that the second run succeeds when the first run fails. So is this an error or not an error?

This needs to be looked at.

Version is from Git Sun Oct 7 22:08:10 2012 +0000

--- log ---
<...skipped...>
== AddMoreChangesetIndexes: migrating ========================================
-- add_index("changesets", ["created_at"], {:name=>"changesets_created_at_idx"})
-> 0.0116s
-- add_index("changesets", ["closed_at"], {:name=>"changesets_closed_at_idx"})
-> 0.0122s
-- add_index("changesets", ["min_lat", "max_lat", "min_lon", "max_lon"], {:method=>"GIST", :name=>"changesets_bbox_idx"})
rake aborted!
An error has occurred, this and all later migrations canceled:

PG::Error: ERROR: data type integer has no default operator class for access method "gist"
HINT: You must specify an operator class for the index or define a default operator class for the data type.
: CREATE INDEX "changesets_bbox_idx" ON "changesets" USING GIST ("min_lat", "max_lat", "min_lon", "max_lon")

Tasks: TOP => db:migrate
(See full trace by running task with --trace)

@openstreetmap-trac
Copy link
Author

Author: jfire
[Added to the original trac issue at 2.18am, Monday, 8th October 2012]

That particular error indicates you need to install the btree_gist extension. For Postgres > 9 the command is psql -d openstreetmap -c "CREATE EXTENSION btree_gist;".

In general you want to be running rake db:setup to initialize a new development database rather than rake db:migrate, which will create the database from db/schema.rb or db/structure.sql (the latter, in the case of the OSM Rails app). Unfortunately, our db/structure.sqlhas some hard-coded paths which need to be adjusted in order to run successfully. This took me a while to figure out when I was first getting going. It would make things easier for new contributors if we could customize the db:setup task such that it worked out of the box, perhaps by generating db/structure.sql from a db/structure.sql.erb file. However, that would also necessitate either manually editing db/structure.sql.erb when the schema changes, or also customizing the db:structure:dump task to write the .erb file.

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 6.08am, Monday, 8th October 2012]

It was never the intention that db:setup be used - the structure.sql is only committed because people asked for it as documentation and frankly committing it is a pain in the arse.

The correct procedure is to manually install btree_gist before running migrate, as I believe the instructions in the wiki tell you to do.

@openstreetmap-trac
Copy link
Author

Author: smsm1
[Added to the original trac issue at 7.58am, Monday, 8th October 2012]

Is there a way to test if the btree_gist has been already installed, and if not we can tell the user and stop running the rake db:migrate. That way the user won't hit the problem of the getting part of the way through the migrations and then getting a strange error.

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 8.21am, Monday, 8th October 2012]

Sure - doing this:

if not select_one("SELECT * FROM pg_opclass WHERE opcname = 'gist_int4_ops'")
throw "Please install the Postgres btree_gist extension in your database"
end

will, if btree_gist is not installed, abort the migrate with:

uncaught throw "Please install the Postgres btree_gist extension in your database"

@openstreetmap-trac
Copy link
Author

Author: jfire
[Added to the original trac issue at 3.26pm, Monday, 8th October 2012]

Replying to [comment:2 TomH]:

It was never the intention that db:setup be used

Is that because of the hard-coded paths, or some other reason? db:setup is the recommended practice, and for good reason in my experience. Migrations, as a means of initializing a fresh database, are slower and more error-prone. Rails does not consider them to be the authoritative source for the schema; structure.sql is.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant