passive_record 0.4.3 → 0.4.4

Sign up to get free protection for your applications and to get access to all the features.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA1:
3
- metadata.gz: 40a7223415652b0909737104ce89ef4b217ea868
4
- data.tar.gz: 6c12988254b55576d5233dc5342efb57885d980d
3
+ metadata.gz: 3bbf676f1d3d94dce7e4b0b0d2faa89476149335
4
+ data.tar.gz: c1607589beb7a3f7cf199cf1f8bdaf67b12568bc
5
5
  SHA512:
6
- metadata.gz: a7ace663d5d19795a44d2db854dbfb1d927d5f17b3f846efe2d7c8e6d360a99339f83045a12c041cadb85426fd3166230b08218dbb84a309d58047780bf1c202
7
- data.tar.gz: 472bc65c4d271b5ee23913163734f1434b45948e7f78331dd55a33c2994cb16449c421bd32c5e1ce42ee42e2d256f1fe04affa8d64e139e95ced64ab578e1253
6
+ metadata.gz: 158a69a9f39cb6cd8df9dae55f2a4554498af25d3044c94d3f1b3af69ed7ee810891efa365470ebb95fddfe151de963d8aa9abc94066638f46ee47259af44acd
7
+ data.tar.gz: 23c5791750f524c311a0e98f3849e7b399f28c883b174635289eb25d1ccfa09662c6b35d4c103d18f18321471feb6579465e9998db66e7ab2edb34232194cf0a
data/README.md CHANGED
@@ -112,9 +112,9 @@ PassiveRecord may be right for you!
112
112
  - `User.destroy_all`
113
113
  - `User.each` enumerates over `User.all`, giving `User.count`, `User.first`, etc.
114
114
  - `User.find(id_or_ids)`
115
- - `User.find_by(name: 'Aloysius')`
116
- - `User.find_all_by(job: ['manager', 'developer', 'qa'])`
117
- - `User.where(birthday: 1.day.ago...1.day.from_now)` (returns a `PassiveRecord::Query` object)
115
+ - `User.find_by(conditions)`
116
+ - `User.find_all_by(conditions)`
117
+ - `User.where(conditions)` (returns a `PassiveRecord::Query` object)
118
118
 
119
119
  ### Belongs To
120
120
 
@@ -199,7 +199,8 @@ PassiveRecord may be right for you!
199
199
  # Prior Art
200
200
 
201
201
  - Approaches exist that use ActiveRecord directly, and then override various methods in such a way to prevent AR from trying to persist the model. The canonical example here is the [tableless model](http://railscasts.com/episodes/193-tableless-model?view=asciicast) approach, and the use case given there is a model that wraps around sending an email. This is maybe interesting because, similar to the round-trip with a database, sending mail is externally "effectful" (and so, for instance, you may wish to take additional care around confirmation or retry logic, in order ensure you are not sending the same message more than once.)
202
- - These approaches are seen as somewhat hacky today, given that [ActiveModel](https://github.com/rails/rails/tree/master/activemodel) can give plain old Ruby objects a lot of the augmentations that ActiveRecord gives, such as validations, hooks and attribute management. However I don't really see a way to do relations that interoperate with ActiveRecord the way you could, at least to some degree, with tableless models. - It's not really clear to me yet if it's interesting for PassiveRecord to be able to interoperate smoothly with ActiveRecord relations. It seems like we might be able to pull some similar tricks as the "tableless" approach in order to permit at least some relations to work between them. But their intentions are so different I can't help but think there would be very strange bugs lurking in any such integration -- so the encouraged architecture would be a complete separation between active and passive models.
202
+ - These approaches are seen as somewhat hacky today, given that [ActiveModel](https://github.com/rails/rails/tree/master/activemodel) can give plain old Ruby objects a lot of the augmentations that ActiveRecord gives, such as validations, hooks and attribute management. However I don't really see a way to do relations that interoperate with ActiveRecord the way you could, at least to some degree, with tableless models.
203
+ - It's not really clear to me yet if it's interesting for PassiveRecord to be able to interoperate smoothly with ActiveRecord relations. It seems like we might be able to pull some similar tricks as the "tableless" approach in order to permit at least some relations to work between them. But their intentions are so different I can't help but think there would be very strange bugs lurking in any such integration -- so the encouraged architecture would be a complete separation between active and passive models.
203
204
 
204
205
  ## Copyright
205
206
 
@@ -1,4 +1,4 @@
1
- require 'ostruct'
1
+ require 'forwardable'
2
2
 
3
3
  require 'active_support'
4
4
  require 'active_support/core_ext/string/inflections'
@@ -1,4 +1,4 @@
1
1
  module PassiveRecord
2
2
  # passive_record version
3
- VERSION = "0.4.3"
3
+ VERSION = "0.4.4"
4
4
  end
metadata CHANGED
@@ -1,14 +1,14 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: passive_record
3
3
  version: !ruby/object:Gem::Version
4
- version: 0.4.3
4
+ version: 0.4.4
5
5
  platform: ruby
6
6
  authors:
7
7
  - Joseph Weissman
8
8
  autorequire:
9
9
  bindir: bin
10
10
  cert_chain: []
11
- date: 2016-04-02 00:00:00.000000000 Z
11
+ date: 2016-04-21 00:00:00.000000000 Z
12
12
  dependencies:
13
13
  - !ruby/object:Gem::Dependency
14
14
  name: activesupport
@@ -185,7 +185,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
185
185
  version: '0'
186
186
  requirements: []
187
187
  rubyforge_project:
188
- rubygems_version: 2.4.6
188
+ rubygems_version: 2.4.8
189
189
  signing_key:
190
190
  specification_version: 4
191
191
  summary: no-persistence relational algebra