attr_json 1.4.0 → 2.6.0

data/README.md

@@ -1,12 +1,12 @@
 # AttrJson
-[![CI Status](https://github.com/jrochkind/attr_json/workflows/CI/badge.svg?branch=master)](https://github.com/jrochkind/attr_json/actions?query=workflow%3ACI+branch%3Amaster)
-[![CI Status](https://github.com/jrochkind/attr_json/workflows/CI%20on%20Future%20Rails%20Versions/badge.svg?branch=master)](https://github.com/jrochkind/attr_json/actions?query=workflow%3A%22CI+on+Future+Rails+Versions%22+branch%3Amaster)
-[![Gem Version](https://badge.fury.io/rb/attr_json.svg)](https://badge.fury.io/rb/attr_json)
 
+[![CI](https://github.com/jrochkind/attr_json/actions/workflows/ci.yml/badge.svg)](https://github.com/jrochkind/attr_json/actions/workflows/ci.yml)
+[![CI on Future Rails Versions](https://github.com/jrochkind/attr_json/actions/workflows/future_rails_ci.yml/badge.svg)](https://github.com/jrochkind/attr_json/actions/workflows/future_rails_ci.yml)
+[![Gem Version](https://badge.fury.io/rb/attr_json.svg)](https://badge.fury.io/rb/attr_json)
 
-ActiveRecord attributes stored serialized in a json column, super smooth. For Rails 5.0 through 6.1. Ruby 2.4+.
+ActiveRecord attributes stored serialized in a json column, super smooth. For Rails 6.0.x through 7.0.x. Ruby 2.7+.
 
-Typed and cast like Active Record. Supporting [nested models](#nested), [dirty tracking](#dirty), some [querying](#querying) (with postgres [jsonb](https://www.postgresql.org/docs/9.5/static/datatype-json.html) contains), and [working smoothy with form builders](#forms).
+Typed and cast like Active Record. Supporting [nested models](#nested), [dirty tracking](#ar_attributes), some [querying](#querying) (with postgres [jsonb](https://www.postgresql.org/docs/9.5/static/datatype-json.html) contains), and [working smoothy with form builders](#forms).
 
 *Use your database as a typed object store via ActiveRecord, in the same models right next to ordinary ActiveRecord column-backed attributes and associations. Your json-serialized `attr_json` attributes use as much of the existing ActiveRecord architecture as we can.*
 
@@ -18,7 +18,7 @@ has not yet been tested with MySQL.
 ## Basic Use
 
 ```ruby
-# migration
+# migration, default column used is `json_attributes, but this can be changed
 class CreatMyModels < ActiveRecord::Migration[5.0]
   def change
     create_table :my_models do |t|
@@ -30,6 +30,14 @@ class CreatMyModels < ActiveRecord::Migration[5.0]
   end
 end
 
+# An embedded model, if desired
+class LangAndValue
+  include AttrJson::Model
+
+  attr_json :lang, :string, default: "en"
+  attr_json :value, :string
+end
+
 class MyModel < ActiveRecord::Base
    include AttrJson::Record
 
@@ -39,14 +47,40 @@ class MyModel < ActiveRecord::Base
    attr_json :my_integer, :integer
    attr_json :my_datetime, :datetime
 
-   # You can have an _array_ of those things too.
+   # You can have an _array_ of those things too. It will ordinarily default to empty array.
    attr_json :int_array, :integer, array: true
 
+   # The empty array default can be disabled with the following setting
+   attr_json :str_array, :string, array: true, default: AttrJson::AttributeDefinition::NO_DEFAULT_PROVIDED
+
    #and/or defaults
-   attr_json :int_with_default, :integer, default: 100
+   attr_json :str_with_default, :string, default: "default value"
+
+   attr_json :embedded_lang_and_val, LangAndValue.to_type
 end
+
+model = MyModel.create!(
+  my_integer: 101,
+  my_datetime: DateTime.new(2001,2,3,4,5,6),
+  embedded_lang_and_val: LangAndValue.new(value: "a sentance in default language english")
+  )
 ```
 
+What will get serialized to your `json_attributes` column will look like:
+
+```json
+{
+  "my_integer":101,
+  "my_datetime":"2001-02-03T04:05:06Z",
+  "str_with_default":"default value",
+  "embedded_lang_and_val": {
+    "lang":"en",
+    "value":"a sentance in default language english"
+  }
+}
+```
+
+
 These attributes have type-casting behavior very much like ordinary ActiveRecord values.
 
 ```ruby
@@ -57,6 +91,8 @@ model.int_array = "12"
 model.int_array # => [12]
 model.my_datetime = "2016-01-01 17:45"
 model.my_datetime # => a Time object representing that, just like AR would cast
+model.embedded_lang_and_val = { value: "val"}
+model.embedded_lang_and_val #=> #<LangAndVal:0x000000010c9a7ad8 @attributes={"value"=>"val"...>
 ```
 
 You can use ordinary ActiveRecord validation methods with `attr_json` attributes.
@@ -64,14 +100,9 @@ You can use ordinary ActiveRecord validation methods with `attr_json` attributes
 All the `attr_json` attributes are serialized to json as keys in a hash, in a database jsonb/json column. By default, in a column `json_attributes`.
 If you look at `model.json_attributes`, you'll see values already cast to their ruby representations.
 
-But one way to see something like what it's really like in the db is to
-save the record and then use the standard Rails `*_before_type_cast` method.
+To see JSON representations, we can use Rails [\*\_before_type_cast](https://api.rubyonrails.org/classes/ActiveRecord/AttributeMethods/BeforeTypeCast.html) methods,  [\*\-in_database](https://api.rubyonrails.org/classes/ActiveRecord/AttributeMethods/Dirty.html#method-i-attribute_in_database) and [\*\_for_database] methods (Rails 7.0+ only).
 
-```ruby
-model.save!
-model.json_attributes_before_type_cast
-# => string containing: {"my_integer":12,"int_array":[12],"my_datetime":"2016-01-01T17:45:00.000Z"}
-```
+These methods can all be called on the container `json_attributes` json hash attribute (generally showing serialized JSON to string), or any individual attribute (generally showing in-memory JSON-able object). [This is a bit confusing and possibly not entirely consistent, needs more investigation.]
 
 ## Specifying db column to use
 
@@ -159,10 +190,8 @@ attribute name, it'll actually query on store_key. And properly handles any
 `container_attribute` -- it'll look in the proper jsonb column.
 
 Anything you can do with `jsonb_contains` should be handled
-by a [postgres `USING GIN` index](https://www.postgresql.org/docs/9.5/static/datatype-json.html#JSON-INDEXING)
-(I think! can anyone help confirm/deny?). To be sure, I recommend you
-investigate: Check out `to_sql` on any query to see what jsonb SQL it generates,
-and explore if you have the indexes you need.
+by a [postgres `USING GIN` index](https://www.postgresql.org/docs/9.5/static/datatype-json.html#JSON-INDEXING). Figuring out how to use indexes for jsonb
+queries can be confusing, [here is a good blog post](https://blog.kiprosh.com/postgres-gin-index-in-rails/).
 
 <a name="nested"></a>
 ## Nested models -- Structured/compound data
@@ -229,6 +258,13 @@ m.attr_jsons_before_type_cast
 
 You can nest AttrJson::Model objects inside each other, as deeply as you like.
 
+You *can* edit nested models "in place", they will be properly saved.
+
+    m.lang_and_value.lang = "de"
+    m.save! # no problem!
+
+For use with Rails forms, you may want to use `attr_json_accepts_nested_attributes_for` (like Rails `accepts_nested_attributes_for`, see doc page on [Use with Forms and Form Builders](https://github.com/jrochkind/attr_json/blob/master/doc_src/forms.md).
+
 ### Model-type defaults
 
 If you want to set a default for an AttrJson::Model type, you should use a proc argument for
@@ -328,6 +364,9 @@ end
 
 class MyTable < ApplicationRecord
   serialize :some_json_column, MyModel.to_serialization_coder
+
+  # NOTE: In Rails 7.1+, write:
+  # serialize :some_json_column, coder: MyModel.to_serialization_coder
 end
 
 MyTable.create(some_json_column: MyModel.new(some_string: "string"))
@@ -386,44 +425,29 @@ Use with Rails form builders is supported pretty painlessly. Including with [sim
 
 If you have nested AttrJson::Models you'd like to use in your forms much like Rails associated records: Where you would use Rails `accepts_nested_attributes_for`, instead `include AttrJson::NestedAttributes` and use `attr_json_accepts_nested_attributes_for`. Multiple levels of nesting are supported.
 
-To get simple_form to properly detect your attribute types, define your attributes with `rails_attribute: true`.  You can default rails_attribute to true with `attr_json_config(default_rails_attribute: true)`
-
 For more info, see doc page on [Use with Forms and Form Builders](doc_src/forms.md).
 
-<a name="dirty"></a>
-## Dirty tracking
+<a name="ar_attributes"></a>
+## ActiveRecord Attributes and Dirty tracking
 
-Full change-tracking, ActiveRecord::Attributes::Dirty-style, is available in
-Rails 5.1+ on `attr_json`s on your ActiveRecord classes that include
-`AttrJson::Record`, by including `AttrJson::Record::Dirty`.
-Change-tracking methods are available off the `attr_json_changes` method.
+We endeavor to make record-level `attr_json` attributes available as standard ActiveRecord attributes, supporting that full API.
 
-```ruby
-class MyModel < ActiveRecord::Base
-   include AttrJson::Record
-   include AttrJson::Record::Dirty
+Standard [Rails dirty tracking](https://api.rubyonrails.org/classes/ActiveModel/Dirty.html) should work properly with AttrJson::Record attributes! We have a test suite demonstrating.
 
-   attr_json :str, :string
-end
+We actually keep the "canonical" copy of data inside the "container attribute" hash in the ActiveRecord model. This is because this is what will actually get saved when you save. So we have two copies, that we do our best to keep in sync.
 
-model = MyModel.new
-model.str = "old"
-model.save
-model.str = "new"
-
-# All and only "new" style dirty tracking methods (Raisl 5.1+)
-# are available:
-
-model.attr_json_changes.saved_changes
-model.attr_json_changes.changes_to_save
-model.attr_json_changes.saved_change_to_str?
-model.attr_json_changes.saved_change_to_str
-model.attr_json_changes.will_save_change_to_str?
-# etc
+They get out of sync if you are doing unusual things like using the ActiveRecord attribute API directly (like calling `write_attribute` with an attr_json attribute). Even if this happens, mostly you won't notice. But one thing it will effect is dirty tracking.
+
+If you ever need to sync the ActiveRecord attribute values from the AttrJson "canonical" copies, you can call `active_record_model.attr_json_sync_to_rails_attributes`. If you wanted to be 100% sure of dirty tracking, I suppose you could always call this method first. Sorry, this is the best we could do!
+
+Note that ActiveRecord DirtyTracking will give you ruby objects, for instance for nested models, you might get:
+
+```ruby
+record_obj.attribute_change_to_be_saved(:nested_model)
+# => [#<object>, #<object>]
 ```
 
-More options are available, including merging changes from 'ordinary'
-ActiveRecord attributes in. See docs on [Dirty Tracking](./doc_src/dirty_tracking.md)
+If you want to see JSON instead, you could call #as_json on the values. The Rails [\*\_before_type_cast](https://api.rubyonrails.org/classes/ActiveRecord/AttributeMethods/BeforeTypeCast.html) and [\*\-in_database](https://api.rubyonrails.org/classes/ActiveRecord/AttributeMethods/Dirty.html#method-i-attribute_in_database) methods may also be useful.
 
 <a name="why"></a>
 ## Do you want this?
@@ -437,7 +461,7 @@ Why might you want this?
 
 * Single-Table Inheritance, with sub-classes that have non-shared
   data fields. You rather not make all those columns, some of which will then also appear
-  to inapplicable sub-classes.
+  to inapplicable sub-classes. (**note** you may have trouble with [ActiveRecord #becomes](https://api.rubyonrails.org/v7.0.4/classes/ActiveRecord/Persistence.html#method-i-becomes) in some versions of Rails due to Rails bug. See https://github.com/jrochkind/attr_json/issues/189 and https://github.com/rails/rails/issues/47538))
 
 * A "content management system" type project, where you need complex
   structured data of various types, maybe needs to be vary depending
@@ -478,15 +502,13 @@ to prevent overwriting other updates from processes.
 
 ## State of Code, and To Be Done
 
-This code is solid and stable and is being used in production by at least a handful of people, including the primary maintainer, jrochkind. 
+This code is solid and stable and is being used in production. If you don't see a lot of activity, it might be because it's stable, rather than abandoned. Check to see if it's passing/supported on recent Rails? We test on "edge" unreleased rails to try to stay ahead of compatibility, and has worked through multiple major Rails verisons with few if any changes needed.
 
-The project is currently getting very little maintainance -- and is still working reliably through Rails releases. It is tested on edge rails and ruby (and has needed very few if any changes with subsequent releases), and I endeavor to keep it working as Rails keeps releasing. 
-
-In order to keep the low-maintenace scenario sustainable, I am *very* cautious accepting new features, especially if they increase code complexity at all. Even if you have a working PR, I may be reluctant to accept it. I'm prioritizing sustainability and stability over new features, and so far this is working out well. However, discussion is always welcome! Especially when paired with code (failing tests for the bugfix or feature you want are super helpful on their own!). 
+In order to keep the low-maintenace scenario sustainable, I am *very* cautious accepting new features, especially if they increase code complexity at all. Even if you have a working PR, I may be reluctant to accept it. I'm prioritizing sustainability and stability over new features, and so far this is working out well. However, discussion is always welcome! Especially when paired with code (failing tests for the bugfix or feature you want are super helpful on their own!).
 
 We are committed to [semantic versioning](https://semver.org/) and will endeavor to release no backwards breaking changes without a major version. We are also serious about minimizing backwards incompat releases altogether (ie minimiing major version releases).
 
-Feedback of any kind of _very welcome_, please feel free to use the issue tracker. It is hard to get a sense of how many people are actually using this, which is helpful both for my own sense of reward and for anyone to get a sense of the size of the userbase -- feel free to say hi and let us know how you are using it! 
+Feedback of any kind of _very welcome_, please feel free to use the issue tracker. It is hard to get a sense of how many people are actually using this, which is helpful both for my own sense of reward and for anyone to get a sense of the size of the userbase -- feel free to say hi and let us know how you are using it!
 
 Except for the jsonb_contains stuff using postgres jsonb contains operator, I don't believe any postgres-specific features are used. It ought to work with MySQL, testing and feedback welcome. (Or a PR to test on MySQL?).  My own interest is postgres.
 
@@ -494,13 +516,9 @@ This is still mostly a single-maintainer operation, so has all the sustainabilit
 
 ### Possible future features:
 
-* Make AttrJson::Model lean more heavily on ActiveModel::Attributes API that did not fully exist in first version of attr_json [hope for a future attr_json 2.0 release]
-
-* Make AttrJson::Record insist on creating rails cover attributes (no longer optional)  and integrating more fully into rails, including rails dirty tricking, eliminating need for custom dirty tracking implementation. Overall decrease in lines of code. Can use jsonb_accessor as guide for some aspects. [hope for inclusion in future attr_json 2.0 release]
+* Make AttrJson::Model lean more heavily on ActiveModel::Attributes API that did not fully exist in first version of attr_json (perhaps not, see https://github.com/jrochkind/attr_json/issues/18)
 
-* partial updates for json hashes would be really nice: Using postgres jsonb merge operators to only overwrite what changed. In my initial attempts, AR doesn't make it easy to customize this. [update: this is hard, probably not coming soon]
-
-* seamless compatibility with ransack [update: not necessarily prioritized]
+* partial updates for json hashes would be really nice: Using postgres jsonb merge operators to only overwrite what changed. In my initial attempts, AR doesn't make it easy to customize this. [update: this is hard, probably not coming soon. See https://github.com/jrochkind/attr_json/issues/143]
 
 * Should we give AttrJson::Model a before_serialize hook that you might
   want to use similar to AR before_save?  Should AttrJson::Models
@@ -533,9 +551,9 @@ We use [appraisal](https://github.com/thoughtbot/appraisal) to test with multipl
 
 There is a `./bin/console` that will give you a console in the context of attr_json and all it's dependencies, including the combustion rails app, and the models defined there.
 
-## Acknowledements and Prior Art
+## Acknowledements, Prior Art, alternatives
 
-* The excellent work [Sean Griffin](https://twitter.com/sgrif) did on ActiveModel::Type
+* The excellent work [sgrif](https://twitter.com/sgrif) did on ActiveModel::Type
   really lays the groundwork and makes this possible. Plus many other Rails developers.
   Rails has a reputation for being composed of messy or poorly designed code, but
   it's some really nice design in Rails that allows us to do some pretty powerful
@@ -555,3 +573,5 @@ There is a `./bin/console` that will give you a console in the context of attr_j
   haven't looked at it too much.
 
 * [store_model](https://github.com/DmitryTsepelev/store_model) was created after `attr_json`, and has some overlapping functionality.
+
+* [store_attribute](https://github.com/palkan/store_attribute) is also a more recent addition. while it's not specifically about JSON, it could be used with an underlying JSON coder to give you typed json attributes.

data/attr_json.gemspec

@@ -11,8 +11,8 @@ Gem::Specification.new do |spec|
 
   spec.summary       = %q{ActiveRecord attributes stored serialized in a json column, super smooth.}
   spec.description   = %q{ActiveRecord attributes stored serialized in a json column, super smooth.
-For Rails 5.0, 5.1, or 5.2. Typed and cast like Active Record. Supporting nested models,
-dirty tracking, some querying (with postgres jsonb contains), and working smoothy with form builders.
+Typed and cast like Active Record. Supporting nested models, dirty tracking, some querying
+(with postgres jsonb contains), and working smoothy with form builders.
 
 Use your database as a typed object store via ActiveRecord, in the same models right next to
 ordinary ActiveRecord column-backed attributes and associations. Your json-serialized attr_json
@@ -40,18 +40,19 @@ attributes use as much of the existing ActiveRecord architecture as we can.}
   spec.executables   = spec.files.grep(%r{^exe/}) { |f| File.basename(f) }
   spec.require_paths = ["lib"]
 
-  spec.required_ruby_version = '>= 2.4.0'
+  spec.required_ruby_version = '>= 2.6.0'
 
-  # Only to get CI to work on versions of Rails other than we release with,
-  # should never release a gem with RAILS_GEM set!
+  # This conditional is only to get CI to work on versions of Rails other than
+  # we release with. The gem should never be released without the activerecord
+  # dependency included just as it is here, should never be released
+  # from an env tht has any of these variables set.
   unless ENV['APPRAISAL_INITIALIZED'] || ENV["TRAVIS"] || ENV['CI']
-    spec.add_runtime_dependency "activerecord", ">= 5.0.0", "< 7.1"
+    spec.add_runtime_dependency "activerecord", ">= 6.0.0", "< 8.2"
   end
 
   spec.add_development_dependency "bundler"
   spec.add_development_dependency "rake", ">= 10.0"
   spec.add_development_dependency "rspec", "~> 3.7"
-  spec.add_development_dependency "database_cleaner", "~> 1.5"
   spec.add_development_dependency "yard-activesupport-concern"
   spec.add_development_dependency "appraisal", "~> 2.2"
 

data/doc_src/forms.md

@@ -31,7 +31,7 @@ With ordinary rails associations handled in the ordinary Rails way, you use [acc
 You can handle a single or array AttrJson::Model attr_json similarly, but you have to:
 
 * include AttrJson::NestedAttributes in your model, and then
-* use our own similar `attr_json_accepts_nested_attributes_for` instead.  It _always_ has `allow_destroy`, and some of the other `accepts_nested_attributes_for` options also don't apply, see method for full options.
+* use our own similar `attr_json_accepts_nested_attributes_for` instead.  It _always_ has `allow_destroy`, and some of the other `accepts_nested_attributes_for` options also don't apply, see method for full options -- we expect you will usually want to use this with the `reject_if: :all_blank` option to ignore hashes with no non-nil values.
 
 ```ruby
 class Event
@@ -47,7 +47,7 @@ class MyRecord < ActiveRecord::Base
   attr_json :one_event, Event.to_type
   attr_json :many_events, Event.to_type, array: true
 
-  attr_json_accepts_nested_attributes_for :one_event, :many_events
+  attr_json_accepts_nested_attributes_for :one_event, :many_events, reject_if: :all_blank
 end
 
 # In a form template...
@@ -109,19 +109,8 @@ Remember to add `include AttrJson::NestedAttributes` to all your AttrJson::Model
 
 One of the nice parts about [simple_form](https://github.com/plataformatec/simple_form) is how you can just give it `f.input`, and it figures out the right input for you.
 
-AttrJson by default, on an ActiveRecord::Base, doesn't register it's `attr_jsons` in the right way for simple_form to reflect and figure out their types. However, you can ask it to with `rails_attribute: true`.
+AttrJson by default registers  `attr_jsons` as Rails attributes, and provides other appropriate implementations in AttrJson::Model classes, such that simple_form should just work. There are limited CI tests in this project to confirm simple_form stays working.
 
-```ruby
-class SomeRecord < ActiveRecord::Base
-  include AttrJson::Record
-
-  attr_json :my_date, :date, rails_attribute: true
-end
-```
-
-This will use the [ActiveRecord::Base.attribute](http://api.rubyonrails.org/classes/ActiveRecord/Attributes/ClassMethods.html) method to register the attribute and type, and SimpleForm will now be able to automatically look up attribute type just as you expect. (Q: Should we make this default on?)
-
-You don't need to do this in your nested AttrJson::Model classes, SimpleForm will already be able to reflect on their attribute types just fine as is.
 
 ### Arrays of simple attributes
 

data/gemfiles/rails_6_0.gemfile

@@ -5,14 +5,15 @@ source "https://rubygems.org"
 gem "combustion", "~> 1.0"
 gem "rails", ">= 6.0.0", "< 6.1"
 gem "pg", "~> 1.0"
-gem "rspec-rails", "~> 4.0"
+gem "rspec-rails", "~> 5.0"
 gem "simple_form", ">= 4.0"
 gem "cocoon", ">= 1.2"
 gem "jquery-rails"
 gem "coffee-rails"
+gem "sprockets-rails"
 gem "capybara", "~> 3.0"
-gem "webdrivers", "~> 4.0"
 gem "selenium-webdriver"
 gem "byebug"
+gem "webdrivers", ">= 5.3.1"
 
 gemspec path: "../"

data/gemfiles/rails_6_1.gemfile

@@ -5,13 +5,13 @@ source "https://rubygems.org"
 gem "combustion", "~> 1.0"
 gem "rails", "~> 6.1.0"
 gem "pg", "~> 1.0"
-gem "rspec-rails", "~> 4.0"
+gem "rspec-rails", "~> 6.0"
 gem "simple_form", ">= 4.0"
 gem "cocoon", ">= 1.2"
 gem "jquery-rails"
 gem "coffee-rails"
+gem "sprockets-rails"
 gem "capybara", "~> 3.0"
-gem "webdrivers", "~> 4.0"
 gem "selenium-webdriver"
 gem "byebug"
 

data/gemfiles/rails_7_0.gemfile

@@ -5,15 +5,14 @@ source "https://rubygems.org"
 gem "combustion", "~> 1.0"
 gem "rails", "~> 7.0.0"
 gem "pg", "~> 1.0"
-gem "rspec-rails", "~> 4.0"
+gem "rspec-rails", "~> 6.0"
 gem "simple_form", ">= 4.0"
 gem "cocoon", ">= 1.2"
 gem "jquery-rails"
 gem "coffee-rails"
+gem "sprockets-rails"
 gem "capybara", "~> 3.0"
-gem "webdrivers", "~> 4.0"
 gem "selenium-webdriver"
 gem "byebug"
-gem "sprockets-rails"
 
 gemspec path: "../"

data/gemfiles/{rails_5_1.gemfile → rails_7_1.gemfile}

@@ -2,16 +2,16 @@
 
 source "https://rubygems.org"
 
-gem "combustion", "~> 0.9.0"
-gem "rails", "~> 5.1.0"
+gem "combustion", "~> 1.0"
+gem "rails", "~> 7.1.0"
 gem "pg", "~> 1.0"
-gem "rspec-rails", "~> 4.0"
+gem "rspec-rails", "~> 6.0"
 gem "simple_form", ">= 4.0"
 gem "cocoon", ">= 1.2"
 gem "jquery-rails"
 gem "coffee-rails"
+gem "sprockets-rails"
 gem "capybara", "~> 3.0"
-gem "webdrivers", "~> 4.0"
 gem "selenium-webdriver"
 gem "byebug"
 

data/gemfiles/{rails_5_2.gemfile → rails_7_2.gemfile}

@@ -2,16 +2,16 @@
 
 source "https://rubygems.org"
 
-gem "combustion", "~> 0.9.0"
-gem "rails", "~> 5.2.0"
+gem "combustion", "~> 1.0"
+gem "rails", "~> 7.2.0"
 gem "pg", "~> 1.0"
-gem "rspec-rails", "~> 4.0"
+gem "rspec-rails", "~> 6.0"
 gem "simple_form", ">= 4.0"
 gem "cocoon", ">= 1.2"
 gem "jquery-rails"
 gem "coffee-rails"
+gem "sprockets-rails"
 gem "capybara", "~> 3.0"
-gem "webdrivers", "~> 4.0"
 gem "selenium-webdriver"
 gem "byebug"
 

data/gemfiles/{rails_5_0.gemfile → rails_8_0.gemfile}

@@ -2,18 +2,17 @@
 
 source "https://rubygems.org"
 
-gem "combustion", "~> 0.9.0"
-gem "rails", "~> 5.0.0"
-gem "pg", "~> 0.18"
-gem "rspec-rails", "~> 4.0"
+gem "combustion", "~> 1.0"
+gem "rails", "~> 8.0.0"
+gem "pg", "~> 1.0"
+gem "rspec-rails", "~> 6.0"
 gem "simple_form", ">= 4.0"
 gem "cocoon", ">= 1.2"
 gem "jquery-rails"
 gem "coffee-rails"
+gem "sprockets-rails"
 gem "capybara", "~> 3.0"
-gem "webdrivers", "~> 4.0"
 gem "selenium-webdriver"
 gem "byebug"
-gem "rails-ujs", require: false
 
 gemspec path: "../"

data/gemfiles/rails_8_1.gemfile

@@ -0,0 +1,18 @@
+# This file was generated by Appraisal
+
+source "https://rubygems.org"
+
+gem "combustion", "~> 1.0"
+gem "rails", "~> 8.1.0"
+gem "pg", "~> 1.0"
+gem "rspec-rails", "~> 6.0"
+gem "simple_form", ">= 4.0"
+gem "cocoon", ">= 1.2"
+gem "jquery-rails"
+gem "coffee-rails"
+gem "sprockets-rails"
+gem "capybara", "~> 3.0"
+gem "selenium-webdriver"
+gem "byebug"
+
+gemspec path: "../"

data/gemfiles/rails_edge.gemfile

@@ -2,18 +2,18 @@
 
 source "https://rubygems.org"
 
-gem "combustion", "~> 1.0"
+gem "combustion", "~> 1.0", github: "pat/combustion"
 gem "rails", git: "https://github.com/rails/rails.git", branch: "main"
 gem "pg", "~> 1.0"
-gem "rspec-rails", "~> 4.0"
+gem "rspec-rails", "~> 6.0"
 gem "simple_form", ">= 4.0"
 gem "cocoon", ">= 1.2"
 gem "jquery-rails"
 gem "coffee-rails"
+gem "sprockets-rails"
 gem "capybara", "~> 3.0"
-gem "webdrivers", "~> 4.0"
 gem "selenium-webdriver"
 gem "byebug"
-gem "sprockets-rails"
+gem "rack", "~> 2.0"
 
 gemspec path: "../"

data/lib/attr_json/attribute_definition/registry.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'attr_json/attribute_definition'
 
 module AttrJson
@@ -25,7 +27,10 @@ module AttrJson
       def initialize(hash = {})
         @name_to_definition = hash.dup
         @store_key_to_definition = {}
-        definitions.each { |d| store_key_index!(d) }
+
+        @name_to_definition.values.each { |d| store_key_index!(d) }
+
+        @container_attributes_registered = Hash.new { Set.new }
       end
 
       def fetch(key, *args, &block)
@@ -46,12 +51,13 @@ module AttrJson
 
       # Can return nil if none found.
       def store_key_lookup(container_attribute, store_key)
-        @store_key_to_definition[container_attribute.to_s] &&
-          @store_key_to_definition[container_attribute.to_s][store_key.to_s]
+        @store_key_to_definition[AttrJson.efficient_to_s(container_attribute)] &&
+          @store_key_to_definition[AttrJson.efficient_to_s(container_attribute)][AttrJson.efficient_to_s(store_key)]
       end
 
       def definitions
-        @name_to_definition.values
+        # Since we are immutable, we can cache this to avoid allocation in a hot spot
+        @stored_definitions ||= @name_to_definition.values
       end
 
       # Returns all registered attributes as an array of symbols
@@ -60,7 +66,7 @@ module AttrJson
       end
 
       def container_attributes
-        @store_key_to_definition.keys.collect(&:to_s)
+        @store_key_to_definition.keys.collect { |s| AttrJson.efficient_to_s(s) }
       end
 
       # This is how you register additional definitions, as a non-mutating
@@ -73,6 +79,32 @@ module AttrJson
         end
       end
 
+
+      # We need to lazily set the container type only the FIRST time
+      #
+      # While also avoiding this triggering ActiveRecord to actually go to DB,
+      # we don't want DB connection forced on boot, that's a problem for many apps,
+      # including that may not have a DB connection in initial development.
+      # (#type_for_attribute forces DB connection)
+      #
+      # AND we need to call container attriubte on SUB-CLASS AGAIN, iff sub-class
+      # has any of it's own new registrations, to make sure we get the right type in
+      # sub-class!
+      #
+      # So we just keep track of whether we've registered ourselves, so we can
+      # first time we need to.
+      #
+      # While current implementation is simple, this has ended up a bit fragile,
+      # a different API that doesn't require us to do this implicitly lazily
+      # might be preferred! But this is what we got for now.
+      def register_container_attribute(attribute_name:, model:)
+        @container_attributes_registered[attribute_name.to_sym] << model
+      end
+
+      def container_attribute_registered?(attribute_name:, model:)
+         @container_attributes_registered[attribute_name.to_sym].include?(model)
+      end
+
       protected
 
       def add!(definition)
@@ -81,17 +113,19 @@ module AttrJson
         end
         @name_to_definition[definition.name.to_sym] = definition
         store_key_index!(definition)
+
+        @stored_definitions = nil
       end
 
       def store_key_index!(definition)
-        container_hash = (@store_key_to_definition[definition.container_attribute.to_s] ||= {})
+        container_hash = (@store_key_to_definition[AttrJson.efficient_to_s(definition.container_attribute)] ||= {})
 
-        if container_hash.has_key?(definition.store_key.to_s)
-          existing = container_hash[definition.store_key.to_s]
+        if container_hash.has_key?(AttrJson.efficient_to_s(definition.store_key))
+          existing = container_hash[AttrJson.efficient_to_s(definition.store_key)]
           raise ArgumentError, "Can't add, store key `#{definition.store_key}` conflicts with existing attribute: #{existing.original_args}"
         end
 
-        container_hash[definition.store_key.to_s] = definition
+        container_hash[AttrJson.efficient_to_s(definition.store_key)] = definition
       end
     end
   end