systematize 0.0.1 → 0.0.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 39619b8bfa011bf992c002bf266e3cc87e074d0c
-  data.tar.gz: 5a1f88232472a5ec70e5d795448b59a93f5beb7d
+  metadata.gz: bd5c0b0659f114baf943c91a9a2bf4a38c255f1a
+  data.tar.gz: cea63ac2678319df2f8dcc85b0874892751bfc17
 SHA512:
-  metadata.gz: 51c3ab97157d5853c4c1d55e9d92396212094d7669b115d30ba0ae1438cfbc3c1ad216af673711cba9745ac8c40bfc229039416b14dc42608d2ea7a4ad65dbf5
-  data.tar.gz: 2ab08ea9995723e086409e78fe4741a0386b7a16cacb332e4f1b9c33bd0a409bf4180eb686e10460daddfdc8f42aef81d150ef65805e4360fdff3532d944c354
+  metadata.gz: 884b4ddf2e107c5b1391133fc26139687b9a23c48d5c305e91ef095ed4c30864053ae1c2587f725618fe2398e64ffec1e0fba71768155fd9d947db04882e3b3d
+  data.tar.gz: 976f29be93ac59ef3769342e37be708d6e9e781c518675d23d248810ad9616125dee1c5b57d252fc2014050fcb2da76685b4ce1816c8344b35c8c9209d3d3cf2

data/README.md

@@ -1,64 +1,85 @@
 # systematize
 
-![shuffler.gif](https://s15.postimg.org/jupy0v0or/shuffler.gif)
+<p align="center">
+<img src="https://s15.postimg.org/jupy0v0or/shuffler.gif" width="100%" />
+</p>
 
-One of the most important things that a ruby application can have are the migrations, but they can be one of 2 kinds:
-- Structural migrations
-- Data migrations
-
-If you want to organize said migrations in their purpose you'll probably have a folder for the struture ones and another for the data ones. But with that separation comes a problem, when should you run one type and when to run the other?
-Probably the sanner way of doing it is we firstly run the structure migrations and after that we run the data migrations, but with this approach one problem will rise:
-
-What if I have a new field that is initially populated taking into account another field, and after that we can delete that other field?
-Imagine the following scenario:
-- You have a `Post` model that initially has a boolean field called `:deleted`.
-- After some time, and some deleted `Posts`, you need to know when that post has been deleted. So you create a `:deleted_at` field that will contain the time os the deletion.
-- You can now delete the old `:deleted` field because it turned obsolete, so you create the migration to do it.
-
-On this scenario we will have 2 structure migrations (create the `:deleted_at` field and removing the `:deleted` field) and a data migration (go through all the Posts and add the time to `:deleted_at` if they are `:deleted`). With previous migration approach, running all the migrations would fail because when the data migration run we would have the `:deleted` field because it was deleted by the structure migration.
+## Why does this even exist ?
 
-This is when `systematize` comes in for the rescue 🚀
+So you can seperate the data and structure migrations in different folders, because you know organization and stuff.
 
 ## Installation
 
-If your using a Gemfile, just add it to your project
-<pre><code>#Gemfile
+If you're using a `Gemfile`, just add it to your project
+```gemfile
+#Gemfile
 gem 'systematize'
-</code></pre>
+```
 
 Or just add it via `bundler`
-<pre><code>bundle install 'systematize'</code></pre>
+```gemfile
+bundle install 'systematize'
+```
 
 ## Structure
 So as the structural migrations live in the `db/migrate` folder, the data migrations shall live in the `db/data` folder:
 
-<pre><code>- app
+```gemfile
+- app
   |
   |-db
     |-data
     |-migrate
-</pre></code>
+```
 
 ## Usage
-After installing you'll se the following tasks pop-up:
+After installing you'll see the following tasks pop-up:
 
-<pre><code>$> bundle exec rake -T
+```bash
+$> bundle exec rake -T
 rake systematize:migrate       # Migrate the database
 rake systematize:rollback      # Rollback the database (options: STEP=x, VERBOSE=false)
 rake systematize:rollback_all  # Rollback all the database
-</pre></code>
+```
 
 Now if you need to migrate the database you just need to run:
-<pre><code>bundle exec rake systematize:migrate</pre></code>
+```bash
+bundle exec rake systematize:migrate
+```
 
 Needing to rollback the previous migration? No problem.
-<pre><code>bundle exec rake systematize:rollback</pre></code>
+```bash
+bundle exec rake systematize:rollback
+```
 
 Need to rollback 2/3/4 migrations? I got you.
-<pre><code>bundle exec rake systematize:rollback STEP=2 </pre></code>
+```bash
+bundle exec rake systematize:rollback STEP=2
+```
+
+Made a mess so big you need to start fresh? Do it. (the migrations need to be reversible 😅)
+```bash
+bundle exec rake systematize:rollback_all
+```
 
-Made a mess so big you need to start fresh? Do it. (the migrations need to be reversible :smile:)
-<pre><code>bundle exec rake systematize:rollback_all </pre></code>
+## Why was this frankstein created ? 👹
+
+One of the most important things that a ruby application can have are the migrations, but they can be one of 2 kinds:
+- Structural migrations
+- Data migrations
+
+If you want to organize said migrations in their purpose you'll probably have a folder for the struture ones and another for the data ones. But with that separation comes a problem, when should you run one type and when to run the other?
+Probably the sanner way of doing it is we firstly run the structure migrations and after that we run the data migrations, but with this approach one problem will rise:
+
+What if I have a new field that is initially populated taking into account another field, and after that we can delete that other field?
+Imagine the following scenario:
+- You have a `Post` model that initially has a boolean field called `:deleted`.
+- After some time, and some deleted `Posts`, you need to know when that post has been deleted. So you create a `:deleted_at` field that will contain the time of the deletion.
+- You can now delete the old `:deleted` field because it turned obsolete, so you create the migration to do it.
+
+On this scenario we will have 2 structure migrations (create the `:deleted_at` field and removing the `:deleted` field) and a data migration (go through all the Posts and add the time to `:deleted_at` if they are `:deleted`). With previous migration approach, running all the migrations would fail because when the data migration run we wouldn't have the `:deleted` field because it was deleted by the structure migration.
+
+This is when `systematize` comes in for the rescue 🚀
 
 ## Caveats
 - The migrations need to follow the Rails convention to them `YYYYMMDDHHMMSS_create_products.rb`
@@ -67,3 +88,14 @@ Made a mess so big you need to start fresh? Do it. (the migrations need to be re
 ## TODO
 - [ ] Customizable folder configuration
 - [ ] Customizable transaction type configuration
+
+## Contributing
+I welcome and encourage all pull requests. It usually will take me within 24-48 hours to respond to any issue or request. Here are some basic rules to follow to ensure timely addition of your request:
+  1. If its a feature, bugfix, or anything please only change code to what you specify.
+  2. Please keep PR titles easy to read and descriptive of changes, this will make them easier to merge :)
+  3. Pull requests _must_ be made against `develop` branch. Any other branch (unless specified by the maintainers) will get rejected.
+  4. Check for existing [issues](https://github.com/brazunisdelamancha/milagre/issues) first, before filing an issue.
+  5. Have fun!
+
+### Created & Maintained By
+[Ricardo Brazão](https://github.com/RicardoBrazao) ([@RicBrazao](https://www.twitter.com/RicBrazao))

data/lib/systematize/version.rb

@@ -1,3 +1,3 @@
 module Systematize
-  VERSION = "0.0.1"
+  VERSION = "0.0.2"
 end

data/lib/tasks/migrations.rake

@@ -24,4 +24,14 @@ namespace :systematize do
       ActiveRecord::Migrator.migrate(temp_folder, 0)
     end
   end
+
+  desc "Create the database"
+  task :create => :environment do
+    Rake::Task["db:create"].invoke
+  end
+
+  desc "Drop the database"
+  task :drop => :environment do
+    Rake::Task["db:drop"].invoke
+  end
 end

data/spec/spec_helper.rb

@@ -1,9 +1,24 @@
 require 'rspec'
 require 'rails'
+require 'active_record'
 require 'systematize'
 require 'pry'
 
+DATABASE_SPEC_FILE = 'spec/support/db/test.sqlite3'
+
 RSpec.configure do |config|
   config.color = true
   config.tty = true
+
+  config.before(:suite) {
+    ActiveRecord::Base.establish_connection(
+      adapter: 'sqlite3',
+      database: DATABASE_SPEC_FILE,
+    )
+  }
+
+  config.after(:suite) {
+    FileUtils.rm(DATABASE_SPEC_FILE)
+    ActiveRecord::Base.connection.close
+  }
 end

data/spec/testapp/Gemfile.lock

@@ -1,9 +1,9 @@
 PATH
   remote: ../../../systematize
   specs:
-    systematize (0.0.1)
-      activerecord
-      railties
+    systematize (0.0.2)
+      activerecord (>= 3.2)
+      railties (>= 3.2)
 
 GEM
   remote: https://rubygems.org/
@@ -45,6 +45,7 @@ GEM
       coffee-script-source
       execjs
     coffee-script-source (1.10.0)
+    diff-lcs (1.3)
     erubis (2.7.0)
     execjs (2.7.0)
     hike (1.2.3)
@@ -91,6 +92,19 @@ GEM
     rake (11.3.0)
     rdoc (3.12.2)
       json (~> 1.4)
+    rspec (3.5.0)
+      rspec-core (~> 3.5.0)
+      rspec-expectations (~> 3.5.0)
+      rspec-mocks (~> 3.5.0)
+    rspec-core (3.5.4)
+      rspec-support (~> 3.5.0)
+    rspec-expectations (3.5.0)
+      diff-lcs (>= 1.2.0, < 2.0)
+      rspec-support (~> 3.5.0)
+    rspec-mocks (3.5.0)
+      diff-lcs (>= 1.2.0, < 2.0)
+      rspec-support (~> 3.5.0)
+    rspec-support (3.5.0)
     sass (3.4.22)
     sass-rails (3.2.6)
       railties (~> 3.2.0)
@@ -119,6 +133,7 @@ DEPENDENCIES
   jquery-rails
   pry
   rails (= 3.2.0)
+  rspec
   sass-rails (~> 3.2.3)
   sqlite3
   systematize!

data/spec/testapp/db/schema.rb

@@ -0,0 +1,25 @@
+# encoding: UTF-8
+# This file is auto-generated from the current state of the database. Instead
+# of editing this file, please use the migrations feature of Active Record to
+# incrementally modify your database, and then regenerate this schema definition.
+#
+# Note that this schema.rb definition is the authoritative source for your
+# database schema. If you need to create the application database on another
+# system, you should be using db:schema:load, not running all the migrations
+# from scratch. The latter is a flawed and unsustainable approach (the more migrations
+# you'll amass, the slower it'll run and the greater likelihood for issues).
+#
+# It's strongly recommended to check this file into your version control system.
+
+ActiveRecord::Schema.define(:version => 20161117152655) do
+
+  create_table "posts", :force => true do |t|
+    t.string   "title"
+    t.string   "description"
+    t.integer  "owner_id"
+    t.datetime "created_at",  :null => false
+    t.datetime "updated_at",  :null => false
+    t.time     "deleted_at"
+  end
+
+end

data/spec/testapp/log/development.log

@@ -951,3 +951,85 @@ Migrating to AddDeletedAtTimestamp (20161117152138)
    (0.2ms)  begin transaction
    (0.0ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" 
    (0.1ms)  commit transaction
+   (0.3ms)  select sqlite_version(*)
+   (0.7ms)  CREATE TABLE "schema_migrations" ("version" varchar(255) NOT NULL) 
+   (0.1ms)  PRAGMA index_list("schema_migrations")
+   (0.6ms)  CREATE UNIQUE INDEX "unique_schema_migrations" ON "schema_migrations" ("version")
+   (0.0ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" 
+Migrating to CreatePostsTable (20161117151622)
+   (0.0ms)  begin transaction
+   (0.3ms)  CREATE TABLE "posts" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "title" varchar(255), "description" varchar(255), "owner_id" integer, "deleted" boolean, "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL) 
+   (0.1ms)  INSERT INTO "schema_migrations" ("version") VALUES ('20161117151622')
+   (0.7ms)  commit transaction
+Migrating to AddDeletedAtTimestamp (20161117152138)
+   (0.0ms)  begin transaction
+   (0.3ms)  ALTER TABLE "posts" ADD "deleted_at" time
+   (0.1ms)  INSERT INTO "schema_migrations" ("version") VALUES ('20161117152138')
+   (0.6ms)  commit transaction
+Migrating to RemoveDeletedColumn (20161117152655)
+   (0.0ms)  begin transaction
+   (0.3ms)  CREATE TEMPORARY TABLE "altered_posts" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "title" varchar(255), "description" varchar(255), "owner_id" integer, "deleted" boolean, "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL, "deleted_at" time) 
+   (0.0ms)  PRAGMA index_list("posts")
+   (0.0ms)  SELECT * FROM "posts"
+   (0.2ms)  DROP TABLE "posts"
+   (0.1ms)  CREATE TABLE "posts" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "title" varchar(255), "description" varchar(255), "owner_id" integer, "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL, "deleted_at" time) 
+   (0.0ms)  PRAGMA index_list("altered_posts")
+   (0.1ms)  SELECT * FROM "altered_posts"
+   (0.2ms)  DROP TABLE "altered_posts"
+   (0.1ms)  INSERT INTO "schema_migrations" ("version") VALUES ('20161117152655')
+   (0.8ms)  commit transaction
+   (0.2ms)  select sqlite_version(*)
+   (0.0ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" 
+   (0.0ms)  PRAGMA index_list("posts")
+   (0.2ms)  begin transaction
+   (0.1ms)  select sqlite_version(*)
+   (0.3ms)  CREATE TABLE "schema_migrations" ("version" varchar(255) NOT NULL) 
+   (0.0ms)  PRAGMA index_list("schema_migrations")
+   (0.8ms)  CREATE UNIQUE INDEX "unique_schema_migrations" ON "schema_migrations" ("version")
+   (0.0ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" 
+Migrating to CreatePostsTable (20161117151622)
+   (0.3ms)  CREATE TABLE "posts" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "title" varchar(255), "description" varchar(255), "owner_id" integer, "deleted" boolean, "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL) 
+   (0.1ms)  INSERT INTO "schema_migrations" ("version") VALUES ('20161117151622')
+Migrating to AddDeletedAtTimestamp (20161117152138)
+   (0.2ms)  ALTER TABLE "posts" ADD "deleted_at" time
+   (0.1ms)  INSERT INTO "schema_migrations" ("version") VALUES ('20161117152138')
+Migrating to MarkDeletedPostsWithTimestamp (20161117152453)
+  Post Load (0.1ms)  SELECT "posts".* FROM "posts" WHERE "posts"."deleted" = 't'
+   (0.0ms)  INSERT INTO "schema_migrations" ("version") VALUES ('20161117152453')
+Migrating to RemoveDeletedColumn (20161117152655)
+   (0.4ms)  CREATE TEMPORARY TABLE "altered_posts" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "title" varchar(255), "description" varchar(255), "owner_id" integer, "deleted" boolean, "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL, "deleted_at" time) 
+   (0.0ms)  PRAGMA index_list("posts")
+   (0.0ms)  SELECT * FROM "posts"
+   (0.1ms)  DROP TABLE "posts"
+   (0.1ms)  CREATE TABLE "posts" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "title" varchar(255), "description" varchar(255), "owner_id" integer, "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL, "deleted_at" time) 
+   (0.0ms)  PRAGMA index_list("altered_posts")
+   (0.0ms)  SELECT * FROM "altered_posts"
+   (0.2ms)  DROP TABLE "altered_posts"
+   (0.1ms)  INSERT INTO "schema_migrations" ("version") VALUES ('20161117152655')
+   (1.1ms)  commit transaction
+   (0.2ms)  begin transaction
+   (0.0ms)  select sqlite_version(*)
+   (0.3ms)  CREATE TABLE "schema_migrations" ("version" varchar(255) NOT NULL) 
+   (0.0ms)  PRAGMA index_list("schema_migrations")
+   (0.2ms)  CREATE UNIQUE INDEX "unique_schema_migrations" ON "schema_migrations" ("version")
+   (0.0ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" 
+Migrating to CreatePostsTable (20161117151622)
+   (0.1ms)  CREATE TABLE "posts" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "title" varchar(255), "description" varchar(255), "owner_id" integer, "deleted" boolean, "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL) 
+   (0.0ms)  INSERT INTO "schema_migrations" ("version") VALUES ('20161117151622')
+Migrating to AddDeletedAtTimestamp (20161117152138)
+   (0.2ms)  ALTER TABLE "posts" ADD "deleted_at" time
+   (0.0ms)  INSERT INTO "schema_migrations" ("version") VALUES ('20161117152138')
+Migrating to MarkDeletedPostsWithTimestamp (20161117152453)
+  Post Load (0.1ms)  SELECT "posts".* FROM "posts" WHERE "posts"."deleted" = 't'
+   (0.1ms)  INSERT INTO "schema_migrations" ("version") VALUES ('20161117152453')
+Migrating to RemoveDeletedColumn (20161117152655)
+   (0.3ms)  CREATE TEMPORARY TABLE "altered_posts" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "title" varchar(255), "description" varchar(255), "owner_id" integer, "deleted" boolean, "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL, "deleted_at" time) 
+   (0.0ms)  PRAGMA index_list("posts")
+   (0.0ms)  SELECT * FROM "posts"
+   (0.1ms)  DROP TABLE "posts"
+   (0.1ms)  CREATE TABLE "posts" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "title" varchar(255), "description" varchar(255), "owner_id" integer, "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL, "deleted_at" time) 
+   (0.0ms)  PRAGMA index_list("altered_posts")
+   (0.0ms)  SELECT * FROM "altered_posts"
+   (0.3ms)  DROP TABLE "altered_posts"
+   (0.0ms)  INSERT INTO "schema_migrations" ("version") VALUES ('20161117152655')
+   (1.9ms)  commit transaction

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: systematize
 version: !ruby/object:Gem::Version
-  version: 0.0.1
+  version: 0.0.2
 platform: ruby
 authors:
 - Ricardo Brazão
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2016-11-25 00:00:00.000000000 Z
+date: 2017-02-07 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activerecord
@@ -66,6 +66,20 @@ dependencies:
     - - ">="
       - !ruby/object:Gem::Version
         version: '0'
+- !ruby/object:Gem::Dependency
+  name: sqlite3
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
 description: Systematize will order your data and struture migrations so you don't
   have to think which one to run first.
 email:
@@ -118,8 +132,8 @@ files:
 - spec/testapp/db/migrate/20161117151622_create_posts_table.rb
 - spec/testapp/db/migrate/20161117152138_add_deleted_at_timestamp.rb
 - spec/testapp/db/migrate/20161117152655_remove_deleted_column.rb
+- spec/testapp/db/schema.rb
 - spec/testapp/db/seeds.rb
-- spec/testapp/db/test.sqlite3
 - spec/testapp/doc/README_FOR_APP
 - spec/testapp/log/development.log
 - spec/testapp/public/404.html
@@ -190,8 +204,8 @@ test_files:
 - spec/testapp/db/migrate/20161117151622_create_posts_table.rb
 - spec/testapp/db/migrate/20161117152138_add_deleted_at_timestamp.rb
 - spec/testapp/db/migrate/20161117152655_remove_deleted_column.rb
+- spec/testapp/db/schema.rb
 - spec/testapp/db/seeds.rb
-- spec/testapp/db/test.sqlite3
 - spec/testapp/doc/README_FOR_APP
 - spec/testapp/Gemfile
 - spec/testapp/Gemfile.lock