setting_accessors 0.3.0 → 1.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
-SHA1:
-  metadata.gz: 6ba51cce908ff75943938e86e01d1aed48b0ccf6
-  data.tar.gz: 7d164c7545cb6adfa0741b8dabf3b4a7bfae5a74
+SHA256:
+  metadata.gz: ccf27bd36edbc82a68d4f3030c58e3582f71c63dafd2289c5fb483bfd8a81263
+  data.tar.gz: 153d794f0323bb0f8518a8331145766df1ca8fc935c88a4419f9b5772c2226db
 SHA512:
-  metadata.gz: ee4917d83045b732589124c938999204b8458859707119faa78d7c2aa3626d4f0949d1cf34afc4d994dda2f4740ceefe4679ff2aec004e7f0382bc2a1c6f1cf7
-  data.tar.gz: 3feb815f194119f2817314c3b6b01880083132eae3972dff75b9ae38c821ae1ee9a4bf105d5105294af7b84ad6c901508a0804f132e5562b0e7a46779bd0ac1f
+  metadata.gz: ff2f5b55fb799e97f14272962f832de8121ee549aa53a7c988a205e7028b4d9b9ad1f5cd5f141a5ce8c8d5d29b494b7ffff2e1ead3929dae4e5df3406f64d285
+  data.tar.gz: 1c7819afb12ef5cfd4de81ca05e6c3c5605eb1c9e2173a977bcd806b64b229443733e13b1c31b18dc3579a1fc17ca1b4677ee6f7d7c47bc701caa2a61e1b32e0

data/.editorconfig

@@ -0,0 +1,10 @@
+[*]
+charset = utf-8
+end_of_line = lf
+indent_size = 2
+indent_style = space
+insert_final_newline = true
+trim_trailing_whitespace = true
+
+[*.md]
+trim_trailing_whitespace = false

data/.rspec

@@ -0,0 +1 @@
+--require spec_helper

data/.rubocop.yml

@@ -0,0 +1,131 @@
+AllCops:
+  TargetRubyVersion: 2.3
+  Exclude:
+    - tmp/**/*
+    - gemfiles/**/*
+
+#---------------------------------------------
+#                   Layout
+#---------------------------------------------
+
+# Hashes do not need padding
+Layout/SpaceInsideHashLiteralBraces:
+  Enabled: false
+
+# Allow 2 space indentation for when inside a case
+Layout/CaseIndentation:
+  Enabled: false
+
+# Allow empty lines in classes
+Layout/EmptyLinesAroundClassBody:
+  Enabled: false
+
+# Allow multiple spaces before first argument
+Layout/SpaceBeforeFirstArg:
+  Enabled: false
+
+# Allow extra spacing, e.g. to align components
+Layout/ExtraSpacing:
+  Enabled: false
+
+# Usually good, but in some cases not possible
+Layout/AlignHash:
+  Enabled: false
+
+# Allow an empty line after do / before end
+Layout/EmptyLinesAroundBlockBody:
+  Enabled: false
+
+# Again, generally a good idea, but it has problems with multiline operations in
+# combination with assignments
+Layout/MultilineOperationIndentation:
+  Enabled: false
+
+# See the corresponding other cops
+Layout/EmptyLinesAroundModuleBody:
+  Enabled: false
+
+Layout/SpaceInLambdaLiteral:
+  Enabled: false
+
+#---------------------------------------------
+#                   Metrics
+#---------------------------------------------
+
+# Allow bigger classes
+Metrics/ClassLength:
+  Enabled: false
+
+Metrics/LineLength:
+  Max: 120
+
+  # To make it possible to copy or click on URIs in the code, we allow lines
+  # containing a URI to be longer than Max.
+  AllowHeredoc: true
+  AllowURI: true
+
+Metrics/BlockLength:
+  Max: 75
+  Exclude:
+    - spec/**/*.rb
+
+# Allow longer methods
+Metrics/MethodLength:
+  Enabled: false
+
+# Allow bigger modules
+Metrics/ModuleLength:
+  Enabled: false
+
+#---------------------------------------------
+#                   Naming
+#---------------------------------------------
+
+Naming/HeredocDelimiterNaming:
+  Enabled: false
+
+#---------------------------------------------
+#                   Style
+#---------------------------------------------
+
+# Allow fail() for initial exception, raise() for re-raise
+# It seems that the cop decision was mainly based on "more people use raise than fail"...
+Style/SignalException:
+  Enabled: false
+
+# Allow assigning multiple variables in one line.
+# This should not be overused, but comes in handy when assigning initializer values to instance variables
+Style/ParallelAssignment:
+  Enabled: false
+
+# Depending on the situation, it might make more sense to use
+# [:symbol1, :symbol2] over %i[symbol1 symbol2], e.g. for multiline aligning reasons.
+Style/SymbolArray:
+  Enabled: false
+
+# Not all modules have to have top level comments
+Style/Documentation:
+  Enabled: false
+
+# Allow class variable usage
+Style/ClassVars:
+  Enabled: false
+
+# Allow block comments
+Style/BlockComments:
+  Enabled: false
+
+# Allow the use of !! (conversion of nil/object to true/false)
+Style/DoubleNegation:
+  Enabled: false
+
+# Allow unless/if blocks even for one-liners
+Style/IfUnlessModifier:
+  Enabled: false
+
+Style/GuardClause:
+  Enabled: false
+
+Style/MissingRespondToMissing:
+  Exclude:
+    - lib/setting_accessors/setting_scaffold.rb

data/.travis.yml

@@ -2,19 +2,23 @@ language: ruby
 cache: bundler
 
 rvm:
-  - 2.2
-  - 2.3.1
+  - 2.3.0
+  - 2.3.3
+  - 2.4.0
+  - 2.4.4
+  - 2.5.0
+  - 2.5.3
 
-env:
-  - DISABLE_DATABASE_ENVIRONMENT_CHECK=1
+gemfile:
+  - gemfiles/rails_4.2.gemfile
+  - gemfiles/rails_5.0.gemfile
+  - gemfiles/rails_5.1.gemfile
+  - gemfiles/rails_5.2.gemfile
 
 before_install: 'gem install bundler'
 script: 'bundle exec rake'
 
 notifications:
   email:
-    recipients:
-      - stex@sterex.de
     on_failure: change
     on_success: never
-

data/Appraisals

@@ -0,0 +1,17 @@
+# frozen_string_literal: true
+
+appraise 'rails-4.2' do
+  gem 'rails', '~> 4.2.0'
+end
+
+appraise 'rails-5.0' do
+  gem 'rails', '~> 5.0.0'
+end
+
+appraise 'rails-5.1' do
+  gem 'rails', '~> 5.1.0'
+end
+
+appraise 'rails-5.2' do
+  gem 'rails', '~> 5.2.0'
+end

data/CHANGELOG.md

@@ -1,5 +1,42 @@
 # Changelog
 
+## 1.0.0
+
+This is almost a complete refactoring of the gem which also removes some not really needed functionality.  
+It is the first release fully compatible with Rails 5.  
+
+New minimum versions:
+
+* Ruby: 2.3
+* Rails: 4.2
+
+#### General
+
+* Removed globally defined settings (`config/settings.yml`) and therefore also global validations and type conversions.  
+  It is still possible to create global Settings, but each developer has to make sure that the assigned
+  value is valid and correctly typed.
+* Type conversion follows AR's type conversions more strictly now.  
+  This means that e.g. assigning `1.0` to a boolean setting will result in `true` instead of `nil` as before.
+* Updating an attribute created through `setting_accessor` now leads to the record being touched,  
+  similar to what would happen when a normal database attribute was changed. (#4)
+* Setting a new value for an attribute created through `attribute_accessor` will now mark
+  the record as "dirty", meaning `changed?` returns true. (#9)  
+  This was especially needed for Rails 5 as it only even performs a database operation in this case.  
+
+#### Tests
+
+* Tests are now written in RSpec
+* The dummy Rails application has been removed and replaced with `with_model`
+* Appraisal was added to test against multiple Rails versions
+
+#### API Changes
+
+* `method_missing` is now part of the SettingScaffold and therefore no longer needed in the actual Setting model.  
+   You should remove `method_missing` from your model.
+* Setting.create_or_update was renamed to Setting.set and now uses a keyword argument for `assignable`
+* `setting_accessor` no longer supports the `fallback` option.  
+   If a `default` option is given, it is automatically used as fallback.
+
 ## 0.3.0
 
-* Fixed a bug that caused setting accessors not being initialized when being called as part of a rake task chain (#6)
+* Fixed a bug that caused setting accessors not being initialized when being called as part of a rake task chain (#6)

data/Gemfile

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 source 'https://rubygems.org'
 
 # Specify your gem's dependencies in setting_accessors.gemspec

data/README.md

@@ -3,6 +3,7 @@ SettingAccessors
 
 [![Gem Version](https://badge.fury.io/rb/setting_accessors.svg)](http://badge.fury.io/rb/setting_accessors)
 [![Build Status](https://travis-ci.org/Stex/setting_accessors.svg?branch=master)](https://travis-ci.org/Stex/setting_accessors)
+[![Maintainability](https://api.codeclimate.com/v1/badges/78becd1d005aab2d1409/maintainability)](https://codeclimate.com/github/Stex/setting_accessors/maintainability)
 
 Sometimes it's handy to keep track of various settings or attributes in ActiveRecord instances and persist them through various requests (and sessions). An example would be to store a items-per-page value for multiple tables in the application per user or probably also set default sorting directions.
 
@@ -11,6 +12,20 @@ The only problem is, that it would be necessary to either keep hundreds of colum
 This gem consists of a global key-value-store, allowing to use both global and record bound settings
 and ActiveRecord integration to add virtual columns to models without having to change the database layout.
 
+Version Information / Backwards Compatibility
+---------------------------------------------
+
+The current version (1.x) is only compatible with Ruby >= 2.3 and Rails >= 4.2.  
+Versions 0.x support older versions of both Ruby and Rails. 
+
+Version 0.x also supported validations and type conversions for globally defined settings
+(`Setting.my_setting = 5`).  
+This was removed in this version, so developers should make sure that the assigned
+value has the correct type themselves.
+
+Validations for class-wise defined `setting_accessor`s can still be realized using 
+ActiveModel's integrated validators as described below.
+
 Installation
 ------------
 
@@ -37,7 +52,6 @@ The gem requires a few additional files to work properly:
 -	A migration to create the settings table
 -	A setting model
 -	An initializer
--	A settings config file (config/settings.yml)
 
 All of them can be generated using the provided generator:
 
@@ -47,12 +61,15 @@ $ rails g setting_accessors:install MODEL_NAME
 
 If no model name is given, the default one (`Setting`) is used.
 
-Usage as a global key-value-store (globally defined and anonymous settings)
+Usage as a global key-value-store 
 -----
 
-In the following, the model name will be assumed as `Setting`, though you may choose its name freely using the provided generator (see above).
+In the following, the model name will be assumed as `Setting`, 
+though you may choose its name freely using the provided generator (see above).
 
-Settings can either be global or assigned to an instance of ActiveRecord::Base. They consist of a name which is unique either in the global scope or within the instance and a value which can be everything that's serializable through YAML.
+Settings can either be global or assigned to an instance of ActiveRecord::Base. 
+They consist of a name which is unique either in the global scope or within the instance 
+and a value which can be everything that's serializable through YAML.
 
 The easiest way to use the settings model is as a global key-value-store without validations and typecasting.
 
@@ -64,7 +81,9 @@ Setting.the_meaning_of_life
 #=> 42
 ```
 
-If the name contains characters which are not allowed due to ruby naming rules, you can also use the methods`Setting[KEY]` resp. `Setting.get(KEY)` to get a setting's value and `Setting[KEY] = VALUE` resp.`Setting.create_or_update(KEY, VALUE)`.
+If the name contains characters which are not allowed due to ruby naming rules, 
+you can also use the methods`Setting[KEY]` resp. `Setting.get(KEY)` to get a setting's value 
+and `Setting[KEY] = VALUE` resp.`Setting.set(KEY, VALUE)`.
 
 Therefore, the following getter methods are equivalent:
 
@@ -79,54 +98,23 @@ For the corresponding setters:
 ```ruby
 Setting.meaning_of_life   = 42
 Setting[:meaning_of_life] = 42
-Setting.create_or_update(:meaning_of_life, 42)
+Setting.set(:meaning_of_life, 42)
 ```
 
-### Globally defined settings with types and validations
-
-As stated above, the initializer will generate a file called `settings.yml` in your application's `config` directory. This file is used to define global settings, an entry consists of:
-
--	The setting's name
--	The setting's type (optional)
--	Validations to be performed when the setting is saved (optional)
--	A default value (optional)
-
-An example would be a simple string setting:
-
-```yaml
-a_string:
-  type: string
-  default: "I am a string!"
-  validations:
-    presence: true
-```
-
-If a setting is defined with a type, automatic type conversion will happen, similar to what ActiveRecord does:
+This makes it also possible to use Ruby's or-equals operator:
 
 ```ruby
-Setting.a_string = 42
-#=> "42"
-```
-
-The default value is used by the functions `Setting.get_or_default` and `Setting.create_default_setting` and a fallback option for assigned settings (see below).
-
-The built-in validations currently support, this might be extended in the future.
-
-| Base Validation | Options                    |
-|:----------------|:---------------------------|
-| `presence`      | `allow_nil`, `allow_blank` |
-| `numericality`  | `only_integer`             |
-| `boolean`       |                       |
-
+Setting.meaning_of_life ||= 42
+Setting[:meaning_of_life] ||= 42
+``` 
 
 ### Assigned Records
 
-Both globally defined settings and "anonymous" settings can also be assigned to
-a instances of `ActiveRecord::Base` without having to define them in the model first.
+Global settings can also be assigned to an instance of `ActiveRecord::Base` without 
+having to define them in the model first.
 
-An example would be the above mentioned saving of "items per page" values for
-various views: Let's say we have an events view and want to save how many
-rows/items each user would like to display.
+An example would be to save "items per page" values for various views: 
+Let's say we have an events view and want to save how many rows/items each user would like to display.
 
 As there might be many views requiring this functionality, it wouldn't make
 sense to define global settings for each of them. Instead, we would use anonymous
@@ -138,122 +126,74 @@ def items_per_page
   default_value = 30
   Setting.get(key, current_user) || default_value
 end
-```
-
-ActiveRecord Integration
-------------------------
-
-The gem adds the method `setting_accessor` to each class which inherits from `ActiveRecord::Base`.
-
-`setting_accessor` takes a setting name and a set of options to customize the accessor's behaviour:
 
-```ruby
-class MyModel < ActiveRecord::Base
-  setting_accessor :a_string, :fallback => :default
+def set_items_per_page
+  key = [controller_path, action_name].join('_')
+  Setting.set(key, params[:per_page], assignable: current_user) || default_value
 end
 ```
 
-This automatically adds most of the helper methods to the model instances which are available for database columns:
+The following calls are equivalent:
 
 ```ruby
-my_model          = MyModel.new
-
-#Setter
-my_model.a_string = 1234
-
-#Getter
-my_model.a_string
-#=> "1234"
-
-#Value before type cast
-my_model.a_string_before_type_cast
-#=> 1234
-
-#Old value
-my_model.a_string_was
-#=> "I am a string!" (fallback value, see below)
-
-#Check if the value was changed
-my_model.a_string_changed?
-#=> true
+Setting[:meaning_of_life, current_universe] = 42
+Setting.set(:meaning_of_life, 42, assignable: current_universe)
 ```
 
-The setting records are only persisted if all settings *and* the main record were valid.
-
-### Integration of globally defined settings
+`[]=` is not an exact alias of `set` here to still support `or-else`:
 
-If a setting with the given name is defined in `config/settings.yml`, validations and type settings are automatically fetched from it, in this case, only the `:fallback` option is allowed.
+```ruby
+Setting[:meaning_of_life, current_universe] ||= 42
+```
 
-As of now, this means that custom validations are also not supported for globally defined settings, this may be changed in the future.
+ActiveRecord Integration
+------------------------
 
-### Class-wise definition of settings
+The gem adds the method `setting_accessor` to each class which inherits from `ActiveRecord::Base`.
 
-If a setting is defined using `setting_accessor` which is not part of `config/settings.yml`, it will only be available in this class. It however may be defined in multiple classes independently.
+It basically generates an `attribute_accessor` with the given name, but also makes sure that
+the value is persisted when the actual record is saved. It also provides the standard attribute helper
+methods ActiveRecord adds for each database column (`ATTRIBUTE_changed?`, `ATTRIBUTE_was`, ...).
 
-Defining a class setting accepts the same options as the config file:
+It aims to simulate an actual database column.
 
 ```ruby
 class MyModel < ActiveRecord::Base
-  setting_accessor :my_setting, :type => :boolean, :default => false
+  setting_accessor :my_setting, type: :boolean, default: false
 end
 ```
 
 ### Options
 
 ```ruby
-:type => :string | :integer | :boolean | :polymorphic
+type: :string | :integer | :boolean | :polymorphic
 ```
 
-`:type` defines the setting's data type. If no type is given, `:polymorhpic`
-is used automatically.
+`:type` defines the setting's data type. If no type is given, `:polymorhpic` is used automatically.
 
 For every other type, the setting's value is automatically converted accordingly
-upon setting it, mimicking ActiveRecord's behaviour regarding database columns.
+upon setting it, mimicking ActiveRecord's type casting based on database types.
 Please note that `:polymorphic` values are saved as is, meaning that you can
 store everything that's serializable.
 
-More types will be added in the future, most likely all database types
-ActiveRecord can handle as well.
-
 ```ruby
-:default => "I am a string!"
+default: Object
 ```
 
-`:default` sets the setting's default value. It can be retrieved either by
-calling `Setting.get_or_default(...)` or defining a `:fallback` on a class setting.
-
-```ruby
-:fallback => :global | :default | Object
-```
+`:default` sets the setting's default value that is returned as long no actual setting exists for
+that name/assignable.
 
-The `:fallback` option specifies which value should be returned in case the
-setting did not receive a value yet:
-
-- `:global` will try to retrieve a global setting (`Setting.NAME`) with the same
-  name as the accessor and return `nil` if it isn't defined.
-- `:default` will return the default value set up either in the accessor method
-  or `config/settings.yml` for globally defined settings.
-- Every other value will be returned as is
-
-
-```ruby
-:validations => {:presence => true}
-:validations => {:numericality => {:only_integer => true}}
-:validations => {:custom => [lambda {|setting| setting.errors.add(:not_42) if setting.value != 42}]}
-:validations => {:custom => [:must_be_42]}
-```
+### Validations
 
-There are some built-in validations (see above), but they should be mostly used for globally defined
-and globally used settings (`Setting.somethingsomething`).
-For model specific settings, you may treat the setting accessors just like normal columns
-and define your validations accordingly, e.g.
+Attributes created by `setting_accessor` can simply be used with `ActiveModel::Validations` the same way
+as other attributes: 
 
 ```ruby
-setting_accessor :my_string, :type => :string
-setting_accessor :my_number, :type => :integer
+setting_accessor :my_string, type: :string
+setting_accessor :my_number, type: :integer
 
-validates :my_string, :presence => true
-validates :my_number, :numericality => {:only_integer => true}
+validates :my_string, presence: true
+validates :my_number, numericality: {only_integer: true}
 ```
 
 Contributing