mv-core 2.2.0 → 2.2.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: ab1d009f28ad7d42d5c3bd4aa052c3bac79a25dd
-  data.tar.gz: 3c1db440ab887e8f16efeb8f43ead8fde721ce3d
+  metadata.gz: 95b749c7932e7978179b53e4ab0dc8face1ab96f
+  data.tar.gz: 7a434f15ec944f890091da0a20608dae0aeeac69
 SHA512:
-  metadata.gz: 4d27d2949d1dcf0ae10ae704b0a4cca6efecbd52b4799b13b70717b4e692866af265627beec0567993c227a7e733cd6c84630e9f5ce8365c23f56db814314c50
-  data.tar.gz: 4b325c5abde253836ecc0b6ed094494906fc3b699b0005e686afc1ef50042168ee733f39e18f41448bdf7c35c335fd3aba137e31ec800d30f58582a3011aeda6
+  metadata.gz: 3e4d963a43ee163fe83564641147d970f7915f35076c627e9535f03c87fc0ad1e27d071812824b13d7ed69c1bf6cea41321de7cbb88af251022f268f9af9f88d
+  data.tar.gz: 2074b4173da82081b6d57b6e9e6cb1f7191f3367ea3e19bd2c675be1ef0cf139e04a77028a0afe2f66436be22fc0b6b02e629658d68a10ae19fdc4fee7d1b05f

data/README.md

@@ -4,7 +4,9 @@
 
 # Define validations in database and use them in model
 
-Project ```Migration Validators``` (MV) makes it possible for RoR developer to define validations directly in db and then bubble them up to model so they available as normal ActiveModel::Validations there. And all that without code duplication.  
+Project ```Migration Validators``` (MV) makes it possible for RoR developer to define validations directly in db and then bubble them up to model so they available as normal ActiveModel::Validations there. And all that without code duplication.
+
+**WARNING** Versions lower than 2.0 are not supported anymore. As results, rails v.3 or older are not supported either.
 
 # Abbreviations
 
@@ -19,6 +21,7 @@ MV - Migration Validators Projects. All gems that belongs to that project are pr
   * [MySQL](#mysql)
   * [SQLite](#sqlite)
 * [Integration with ActiveRecord](#integration-with-activerecord)
+* [SchemaRb](#schemarb)
 * [Tasks](#tasks)
 * [Drivers](#drivers)
 * [Version History](#version history)
@@ -26,13 +29,13 @@ MV - Migration Validators Projects. All gems that belongs to that project are pr
 
 # Why `Migration Validators`
 
-It's commonly accepted in RoR community to ignore database constraints and define data validations in ActiveModel. In most cases such approach is perfectly acceptable and allows developer to concentrate on business logic rather than on writing database - specific code. 
+It's commonly accepted in RoR community to ignore database constraints and define data validations in ActiveModel. In most cases such approach is perfectly acceptable and allows developer to concentrate on business logic rather than on writing database - specific code.
 
-But when your application grows significantly then possibility of the data error with such approach became more tangible. Data consistency could be violated in many ways: directly ( with db console for ex ), as result of some error in the code, by other application if database is shared. 
+But when your application grows significantly then possibility of the data error with such approach became more tangible. Data consistency could be violated in many ways: directly ( with db console for ex ), as result of some error in the code, by other application if database is shared.
 
-DB constraints could help in such case. But there are several reasons why they are not widely spread in RoR: such constraints are DB - specific in most cases and their management is quite tricky. 
+DB constraints could help in such case. But there are several reasons why they are not widely spread in RoR: such constraints are DB - specific in most cases and their management is quite tricky.
 
-The goal of the `Migration Validators` project is to resolve those problems and make DB constraints management straightforward 
+The goal of the `Migration Validators` project is to resolve those problems and make DB constraints management straightforward
 
 # How It Works
 
@@ -40,7 +43,7 @@ The goal of the `Migration Validators` project is to resolve those problems and
 
 Most of the validations could be defined in several ways: as condition inside trigger, as condition inside check constraint or as index ( for ```uniqueness```)
 
-In most cases developer can select how and where validation should be implemented. By default most optimal way is proposed. 
+In most cases developer can select how and where validation should be implemented. By default most optimal way is proposed.
 
 For example: ```uniqueness``` validation is defined as unique index by default. But developer can select other way - trigger of check constraint. Each way has own advantages and disadvantages
 
@@ -49,17 +52,17 @@ For example: ```uniqueness``` validation is defined as unique index by default.
   Create new table:
 
   ```ruby
-  def change 
+  def change
     create_table do |t|
-      t.string :str_column, validates: { uniqueness: :true, 
+      t.string :str_column, validates: { uniqueness: :true,
                                          inclusion: { in: 1..3 }}
       t.column :column_name, :integer, validates: { exclusion: { in: [1,2,3]}}
     end
   end
   ```
 
-  Modify existing table: 
-  
+  Modify existing table:
+
   ```ruby
   def up
     change_table do |t|
@@ -76,7 +79,7 @@ For example: ```uniqueness``` validation is defined as unique index by default.
   end
   ```
 
-  Update validation definition: 
+  Update validation definition:
 
   ```ruby
   def up
@@ -88,8 +91,8 @@ For example: ```uniqueness``` validation is defined as unique index by default.
   end
   ```
 
- There are many ways to define desired database constraint. And those ways might vary for each RDBMS. One could define the way how constraint should be 
- defined in DB: 
+ There are many ways to define desired database constraint. And those ways might vary for each RDBMS. One could define the way how constraint should be
+ defined in DB:
 
   as trigger:
 
@@ -115,9 +118,9 @@ For example: ```uniqueness``` validation is defined as unique index by default.
   end
   ```
 
-  Also there is possibility to define when validations should occur: 
+  Also there is possibility to define when validations should occur:
 
-  when new record created: 
+  when new record created:
 
   ```ruby
   def up
@@ -141,12 +144,12 @@ For example: ```uniqueness``` validation is defined as unique index by default.
   end
   ```
 
-  And if you need to define some custom validation you can use custom validation (version >= 2.1 is required): 
+  And if you need to define some custom validation you can use custom validation (version >= 2.1 is required):
 
   ```ruby
   def up
-    validates :table_name, :str_column, 
-                      custom: { statement: 'LENGTH(TRIM({str_column})) > 10', 
+    validates :table_name, :str_column,
+                      custom: { statement: 'LENGTH(TRIM({str_column})) > 10',
                                 on: :update }
   end
 
@@ -156,8 +159,8 @@ For example: ```uniqueness``` validation is defined as unique index by default.
   ```
 
   as result only values with length greater than 10 will be allowed and that condition will be implemented inside ON UPDATE trigger
-  
-  Almost all validations supports shorter notation (simplification) that is not compatible with ActiveRecord validation but much shorter (version >= 2.1 is required): 
+
+  Almost all validations supports shorter notation (simplification) that is not compatible with ActiveRecord validation but much shorter (version >= 2.1 is required):
 
   ```ruby
   def up
@@ -181,7 +184,7 @@ For example: ```uniqueness``` validation is defined as unique index by default.
 
   ```ruby
   def up
-    validates :table_name, :str_column, custom: 
+    validates :table_name, :str_column, custom:
                            'LENGTH(TRIM({str_column})) > 10'
   end
 
@@ -190,13 +193,13 @@ For example: ```uniqueness``` validation is defined as unique index by default.
   end
   ```
 
-  Supported validators, simplification and their properties might vary from one db driver to another. See detailed properties description in correspondent [driver](#drivers) section.  
+  Supported validators, simplification and their properties might vary from one db driver to another. See detailed properties description in correspondent [driver](#drivers) section.
 
 # Installation
 
-`mv-core` is a set of core classes that are used everywhere across `Migration Validators` project gems. 
+`mv-core` is a set of core classes that are used everywhere across `Migration Validators` project gems.
 
-This gem is not intended to be installed directly and referenced from within the application. You should rather install appropriate driver. 
+This gem is not intended to be installed directly and referenced from within the application. You should rather install appropriate driver.
 
 ### PostgreSQL:
 
@@ -210,19 +213,19 @@ This gem is not intended to be installed directly and referenced from within the
   gem install mv-mysql
   ```
 
-### SQLite: 
+### SQLite:
 
   ```
   gem install mv-sqlite
   ```
- 
+
 # Integration With ActiveRecord
 
-You can level up validations that are defined in DB to your model using `enforce_migration_validations` method. 
+You can level up validations that are defined in DB to your model using `enforce_migration_validations` method.
 
-Example: 
+Example:
 
-migration: 
+migration:
 
 ```ruby
   def change
@@ -232,7 +235,7 @@ migration:
   end
 ```
 
-model: 
+model:
 
 ```ruby
   class Post << ActiveRecord::Base
@@ -240,18 +243,39 @@ model:
   end
 ```
 
-console: 
+console:
 
 ```ruby
   p = Post.new(title: nil)
 
-  p.valid? 
+  p.valid?
   => false
 
   p.errors.full_messages
   => ["Title can't be blank"]
 ```
 
+# SchemaRb
+
+  All validations that you've defined are dumped to schema.rb automatically:
+
+  in migration:
+
+```ruby
+  def change
+    create_table :posts do |t|
+      t.string :title, presence: { message: "can't be blank", as: :trigger }
+    end
+  end
+```
+
+in 'schema.rb':
+
+```ruby
+  validates(:posts, :title,
+                    presence: { message: "can't be blank", as: :trigger})
+```
+
 # Tasks
 
   Show all constraints on the specified tables:
@@ -260,7 +284,7 @@ console:
   bundle exec rake mv:show_constraints['table_name other_table_name']
   ```
 
-  or show all constraints are created in migrations: 
+  or show all constraints are created in migrations:
 
   ```ruby
   bundle exec rake mv:show_constraints
@@ -272,25 +296,25 @@ console:
   bundle exec rake mv:delete_constraints['table_name other_table_name']
   ```
 
-  or remove all constraints are created in migrations: 
+  or remove all constraints are created in migrations:
 
   ```ruby
   bundle exec rake mv:delete_constraints
   ```
 
-  Create / restore / update constraints on the specified tables: 
+  Create / restore / update constraints on the specified tables:
 
   ```ruby
   bundle exec rake mv:create_constraints['table_name other_table_name']
   ```
 
-  or do it for the all tables: 
+  or do it for the all tables:
 
   ```ruby
   bundle exec rake mv:create_constraints
   ```
 
-  Remove all constraints and drop `migration_validators` table: 
+  Remove all constraints and drop `migration_validators` table:
 
   ```ruby
   bundle exec rake mv:uninstall
@@ -306,7 +330,7 @@ console:
 
 Currently there are drivers for MySQL, PostgreSQL and SQLite RDBMS
 
-So - see detailed info here: 
+So - see detailed info here:
 
 * PostgreSQL: https://github.com/vprokopchuk256/mv-postgresql
 * MySQL: https://github.com/vprokopchuk256/mv-mysql
@@ -320,12 +344,16 @@ So - see detailed info here:
 
 **(2.1.0)** (22 Jan, 2015)
 
-* Custom validation 
+* Custom validation
 
 **(2.2.0)** (28 Jan, 2015)
 
 * Integration with ActiveRecord
 
+**(2.2.1)** (20 Jul, 2015)
+
+* Fix issue with invalid parameters number in `add_column` and `change_column` methods
+
 ## Contributing
 
 * Check out the latest master to make sure the feature hasn't been implemented or the bug hasn't been fixed yet

data/lib/mv/core/active_record/connection_adapters/abstract_adapter_decorator.rb

@@ -6,16 +6,16 @@ module Mv
     module ActiveRecord
       module ConnectionAdapters
         module AbstractAdapterDecorator
-          def add_column table_name, column_name, type, opts
-            Mv::Core::Migration::Base.add_column(table_name, column_name, params(opts))  
-            
-            super 
+          def add_column table_name, column_name, type, opts = {}
+            Mv::Core::Migration::Base.add_column(table_name, column_name, params(opts))
+
+            super
           end
 
           def remove_column table_name, column_name, type = nil, options = {}
             Mv::Core::Migration::Base.remove_column table_name, column_name
 
-            super 
+            super
           end
 
           def rename_column table_name, old_column_name, new_column_name
@@ -24,7 +24,7 @@ module Mv
             super
           end
 
-          def change_column table_name, column_name, type, opts
+          def change_column table_name, column_name, type, opts = {}
             Mv::Core::Migration::Base.change_column(table_name, column_name, params(opts))
 
             super
@@ -55,4 +55,4 @@ module Mv
       end
     end
   end
-end
+end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: mv-core
 version: !ruby/object:Gem::Version
-  version: 2.2.0
+  version: 2.2.1
 platform: ruby
 authors:
 - Valeriy Prokopchuk
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2015-01-28 00:00:00.000000000 Z
+date: 2015-07-20 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: railties