[OpenStreetMap] #4613: Installing fresh openstreetmap database fails
Tom Hughes
tom at compton.nu
Tue Oct 9 21:09:50 BST 2012
On 08/10/12 16:26, OpenStreetMap wrote:
> 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.
I've looked into this a bit, because this was the first I had heard that
the migrations were not supposed to be the authoritative source.
I think this is probably something where best practice has changed at
some point and has passed me by - certainly the comments rails adds
these days makes it clear that the intention is as you say.
Obviously the normal case would be to have a schema.rb file but we have
switched to SQL mode because we have various things in the database that
are not supported directly by the ruby schema DSL.
The bigger problem with making structure.sql and db:setup the preferred
way to setup a database is that there are several things in there which
are not setup by the migrations at all, and which are non-portable
and/or require database superuser privileges to run.
The first of those is the btree_gist extension referenced in the ticket
which both needs superuser privileges and which will only work in 9.1
and later as earlier versions did not support packaged extensions like
that and instead just had an SQL script that installed a bunch of types
and functions etc.
The second is our 3GL functions, which both need superuser privileges
and also wind up embedding a fully qualified filesystem path to the
shard object, which is not portable to different machines.
Suggestions for how to deal with these would be welcome...
Tom
--
Tom Hughes (tom at compton.nu)
http://compton.nu/
More information about the rails-dev
mailing list