Ruby 3.1 compatibility

Adds support for Ruby 3.1, backported from #97 (thanks, @skunkworker).

Ruby 3.1 compatibility

Adds support for Ruby 3.1, backported from #97 (thanks, @skunkworker).

Rails v7.0 compatibility

Adds support for Rails 7.0 (#96) and Ruby 3.1 (#97) (thanks to @skunkworker).

Speed up boolean typecasting

Check for actual boolean value (true, false) when typecasting booleans which is a significant performance gain when using Protobuf (@abrandoned, #67).

v3.2.1

Minor updates to use a different internal API.

Rails 5.1 compatibility, override default endpoints

Previously, the persistence and search modules used hard-coded values for RPC endpoints: :create, :delete, :destroy, :search, :update.

Add DSL methods so that these default values can be overridden:

class Developer < ActiveRemote::Base
  endpoint_for_create :register
  endpoint_for_destroy :delete
end

Also dial in Rails version since ActiveRemote is not yet compatible with Rails v5.2.

Fixes for create, DateTime parsing

Allow primary_key to be set on create

Active Record allows the primary key to be set on create. Active Remote now behaves the same way by allowing the primary key attribute to be sent in a create operation. [#61, @mattnichols]

Handle invalid DateTime attributes gracefully

The Date typecaster will gracefully handle invalid dates, but DateTime did not. Change the behavior of DateTime types to match the behavior of Date types. [#62, @brianstien]

Prep for sending primary key on create

Active Record allows the primary key to be set on create, but Active Remote does not. This makes ActiveRemote#create behave the same way by allowing the primary_key attribute to be sent in a create operation.

Cutting a pre-release to make sure this doesn't have any unexpected side affects.

Safely handle Protobuf errors

Guard against undefined method errors in the Protobuf adapter. [#59, @brianstien]

Add granular Protobuf errors

Active Remote now bubbles up the type of error given from Protobuf instead of a generic ActiveRemoteError. [#58, @ryanbjones]