env variable. README updates.
This commit is contained in:
parent
e9ceb343ac
commit
d1df5b9325
|
|
@ -1,2 +1,4 @@
|
||||||
target
|
target
|
||||||
|
|
||||||
|
*.swp
|
||||||
|
|
||||||
|
|
|
||||||
9
Gemfile
9
Gemfile
|
|
@ -1,3 +1,10 @@
|
||||||
source 'https://rubygems.org'
|
source 'https://rubygems.org'
|
||||||
|
|
||||||
gem 'pg_migrate', :path=> '~/workspace/pg_migrate_ruby'
|
# Look for $WORKSPACE, otherwise use "workspace" as dev path.
|
||||||
|
workspace = ENV["WORKSPACE"] || "workspace"
|
||||||
|
|
||||||
|
# Assumes you have already cloned pg_migrate_ruby in your workspace
|
||||||
|
# $ cd [workspace]
|
||||||
|
# $ git clone https://github.com/sethcall/pg_migrate_ruby
|
||||||
|
|
||||||
|
gem 'pg_migrate', :path=> '~/' + workspace + '/pg_migrate_ruby'
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,22 @@
|
||||||
|
PATH
|
||||||
|
remote: ~/dev/pg_migrate_ruby
|
||||||
|
specs:
|
||||||
|
pg_migrate (0.1.0)
|
||||||
|
logging (= 1.7.2)
|
||||||
|
pg (= 0.14.0)
|
||||||
|
thor (= 0.15.4)
|
||||||
|
|
||||||
|
GEM
|
||||||
|
remote: https://rubygems.org/
|
||||||
|
specs:
|
||||||
|
little-plugger (1.1.3)
|
||||||
|
logging (1.7.2)
|
||||||
|
little-plugger (>= 1.1.3)
|
||||||
|
pg (0.14.0)
|
||||||
|
thor (0.15.4)
|
||||||
|
|
||||||
|
PLATFORMS
|
||||||
|
ruby
|
||||||
|
|
||||||
|
DEPENDENCIES
|
||||||
|
pg_migrate!
|
||||||
6
README
6
README
|
|
@ -5,14 +5,16 @@ Schema migrations for the jam-db database. Uses the [pg_migrate tool](https://g
|
||||||
|
|
||||||
Overview
|
Overview
|
||||||
--------
|
--------
|
||||||
jam-db defines the migrations that comprise the jam-db database. It uses pg_migrate to package up the migrations iinto a gem or (TODO) jar. You can then use those packaged up versions of the schemas in downstream projects.
|
am-db defines the migrations that comprise the jam-db database. It uses pg_migrate to package up the migrations into a gem or (TODO) jar. You can then use those packaged up versions of the schemas in downstream projects.
|
||||||
|
|
||||||
The main reason the 'pg_migrate' approach is taken is to make to possible to use the database like an interface, freed from any one project or language.
|
The main reason the 'pg_migrate' approach is taken is to make to possible to use the database like an interface, freed from any one project or language.
|
||||||
|
|
||||||
Environmenti
|
Environment
|
||||||
-----------
|
-----------
|
||||||
* [rvm](https://rvm.io/) with ruby 1.9.3 installed and activated. rvm needs to be activated in your shell (the installation process does this)
|
* [rvm](https://rvm.io/) with ruby 1.9.3 installed and activated. rvm needs to be activated in your shell (the installation process does this)
|
||||||
* bash . If on windows, use git bash or cygwin. Bash is used as the build script technology. (could change very easily)
|
* bash . If on windows, use git bash or cygwin. Bash is used as the build script technology. (could change very easily)
|
||||||
|
* Definition of location for your developer workspace. Default is ~/workspace, but if you define an env variable, you can override.
|
||||||
|
* pg_migrate_ruby - $ cd [workspace] && git clone https://github.com/sethcall/pg_migrate_ruby
|
||||||
* NOT YET: $IVY defined as path to the [apache ivy jar](http://ant.apache.org/ivy/download.cgi). Download the latest ivy from here, extract somewhere, and create an IVY environment variable with a path to the ivy.jar. For example, in my bash.profile: `export IVY=/Users/seth/workspace/apache-ivy-2.3.0-rc1/ivy-2.3.0-rc1.jar`
|
* NOT YET: $IVY defined as path to the [apache ivy jar](http://ant.apache.org/ivy/download.cgi). Download the latest ivy from here, extract somewhere, and create an IVY environment variable with a path to the ivy.jar. For example, in my bash.profile: `export IVY=/Users/seth/workspace/apache-ivy-2.3.0-rc1/ivy-2.3.0-rc1.jar`
|
||||||
|
|
||||||
Building
|
Building
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue