dynamic-records-meritfront 3.0.1 → 3.0.3

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
  SHA256:
3
- metadata.gz: 6a2496e72da8096b231edb9fab7d9a469926bbcd9a698d0224a78ee7ed5e25a5
4
- data.tar.gz: 23100e7e24dad43bdfeab2f1291d4616c72e3726eba69a1c3cb2be99cf73df19
3
+ metadata.gz: 15173d17ad833e673910fc87f1dd1c6801105086f9a36e2042154c3e624fbc50
4
+ data.tar.gz: 171e89a86eef3b0f75a92a75b4226ab401eda42ad9dd83bb4bed16b92ae439db
5
5
  SHA512:
6
- metadata.gz: a2861fed694119175940f5153f429491cc25210611da866e55b5a52720610655a89b8291dd7bf1a1042fa155ce8c7dbeacbb846470e01645dda9381d868c6b42
7
- data.tar.gz: 84110301448a31b997b6acbd89b99dfbe3d5b3c6432e7ba7cafc20b78bfa92a80818a4291da6a30090643fc7eec3da2028f8a30030339e0ac7cdd90f7c12d49a
6
+ metadata.gz: 20cae9b9c791929d29002d171a837291c1e9315dc9bbb6b4a408212dd98ce408aae270a1b52caeb91f73995ac086e4ff9afd771b9a2a51878bea400881141c88
7
+ data.tar.gz: 551ef2074974ae385c9759ac58c2c170faeb835ed87ca166d7ccfe38779b6f2d03d2f3a3fc06c53e3a05c38a93ccf014a240f13a7b78eb227810d8fcc5928151
data/Gemfile.lock CHANGED
@@ -1,7 +1,7 @@
1
1
  PATH
2
2
  remote: .
3
3
  specs:
4
- dynamic-records-meritfront (3.0.1)
4
+ dynamic-records-meritfront (3.0.3)
5
5
  hashid-rails
6
6
 
7
7
  GEM
data/README.md CHANGED
@@ -11,14 +11,12 @@ Note that postgres is currently a requirement for this gem.
11
11
  ```ruby
12
12
  # returns a json-like hash list of user data
13
13
  users = ApplicationRecord.dynamic_sql(
14
- 'get_5_users',
15
14
  'select * from users limit :our_limit',
16
15
  our_limit: 5
17
16
  )
18
17
 
19
18
  #returns a list of users (each an instance of User)
20
19
  users = User.dynamic_sql(
21
- 'get_users_from_ids',
22
20
  'select * from users where id = ANY (:ids)',
23
21
  ids: [1,2,3]
24
22
  )
@@ -53,28 +51,34 @@ Or install it yourself as:
53
51
  class ApplicationRecord < ActiveRecord::Base
54
52
  self.abstract_class = true
55
53
  include DynamicRecordsMeritfront
56
- DYNAMIC_SQL_RAW = false #<--- not required, but suggested to be turned off. Can be switched on for a per-request basis. Make sure this line is after include statement.
54
+
55
+ #DYNAMIC_SQL_RAW determines whether dynamic_sql method returns a ActiveRecord::Response object or an Array.
56
+ #They both have pros and cons. False returns the array.
57
+ DynamicRecordsMeritfront::DYNAMIC_SQL_RAW = false
57
58
  end
58
59
  ```
59
60
 
60
61
  ### SQL methods
61
62
 
62
- These are methods written for easier sql usage.
63
+ Methods written for easier sql usage.
63
64
 
64
- #### self.dynamic_sql(name, sql, opts = { })
65
+ #### self.dynamic_sql( *optional* name, sql, opts = { })
65
66
  A better and safer way to write sql. Can return either a Hash, ActiveRecord::Response object, or an instantiated model.
66
67
 
68
+ ```ruby
69
+ User.dynamic_sql('select * from users') #returns all users
70
+ ApplicationRecord.dynamic_sql('select id from users', raw: true).rows.flatten #get just the users ids
71
+ ```
72
+
67
73
  with options:
68
74
  - options not stated below: considered sql arguments, and will replace their ":option_name" with a sql argument. Always use sql arguments to avoid sql injection. Lists are converted into a format such as ```{1,2,3,4}```. Lists of lists are converted into ```(1,2,3), (4,5,6), (7,8,9)``` etc. So as to allow easy inserts/upserts.
69
75
  - raw: whether to return a ActiveRecord::Response object or a hash when called on an abstract class (like ApplicationRecord). Default can be switched with DYNAMIC_SQL_RAW variable on the class level.
70
- - instantiate_class: determines what format to return. Can return ActiveRecord objects (User, Post, etc), or whatever raw is set to. I prefer doing the alterantive ```User.dynamic_sql(...)``` which is also supported. For example, ```User.dynamic_sql(...)``` will return User records. ```ApplicationRecord.dynamic_sql(..., raw: false)``` will return a List of Hashes with the column names as keys. ```ApplicationRecord.dynamic_sql(..., raw: true)``` will return an ActiveRecord::Response.
71
76
 
72
- other options:
77
+ other less critical options:
73
78
 
74
79
  - prepare: Defaults to true. Gets passed to ActiveRecord::Base.connection.exec_query as a parameter. Should change whether the command will be prepared, which means that on subsequent calls the command will be faster. Downsides are when, for example, the sql query has hard-coded arguments, the query always changes, causing technical issues as the number of prepared statements stack up.
75
- - name_modifiers: allows one to change the associated name dynamically.
76
80
  - multi_query: allows more than one query (you can seperate an insert and an update with ';' I dont know how else to say it.)
77
- this disables other options including arguments (except name_modifiers). Not sure how it effects prepared statements. Not super useful.
81
+ this disables other options including sql_arguments. Not sure how it effects prepared statements. Not super useful.
78
82
  - async: Defaults to false. Gets passed to ActiveRecord::Base.connection.exec_query as a parameter. See that methods documentation for more. I was looking through the source code, and I think it only effects how it logs to the logfile?
79
83
 
80
84
  <details>
@@ -91,7 +95,7 @@ Delete Friend Requests between two users after they have become friends.
91
95
  </details>
92
96
 
93
97
  <details>
94
- <summary>dynamic sql example usage</summary>
98
+ <summary>example usage with interpreted sql string</summary>
95
99
  Get all users who have made a friend request to a particular user with an optional limit.
96
100
  This is an example of why this method is good for dynamic prepared statements.
97
101
 
@@ -106,9 +110,7 @@ This is an example of why this method is good for dynamic prepared statements.
106
110
  ) AS all_friend_requests
107
111
  ORDER BY all_friend_requests.created_at DESC
108
112
  #{"LIMIT :limit" if limit > 0}
109
- }, uid: u, limit: limit, name_modifiers: [
110
- limit > 0 ? 'limited' : nil
111
- ])
113
+ }, uid: u, limit: limit)
112
114
  ```
113
115
  </details>
114
116
 
@@ -117,13 +119,13 @@ This is an example of why this method is good for dynamic prepared statements.
117
119
 
118
120
  ```ruby
119
121
  #get a normal test vote
120
- test = Vote.dynamic_sql('test', %Q{
122
+ test = Vote.dynamic_sql(%Q{
121
123
  SELECT id FROM votes LIMIT 1
122
124
  }).first
123
125
  v.inspect # "#<Vote id: 696969>"
124
126
 
125
127
  #get a cool test vote. Note that is_this_vote_cool is not on the vote table.
126
- test = Vote.dynamic_sql('test', %Q{
128
+ test = Vote.dynamic_sql(%Q{
127
129
  SELECT id, 'yes' AS is_this_vote_cool FROM votes LIMIT 1
128
130
  }).first
129
131
  test.inspect # #<Vote id: 696969, is_this_vote_cool: "yes"> #getting attributes added dynamically to the models, and also showing up on inspects, was... more difficult than i anticipated.
@@ -175,6 +177,10 @@ This will output sql similar to below. Note this can be done for multiple conver
175
177
  #### self.dynamic_preload(records, associations)
176
178
  Preloads from a list of records, and not from a ActiveRecord_Relation. This will be useful when using the above dynamic_sql method (as it returns a list of records, and not a record relation). This is basically the same as a normal relation preload but it works on a list.
177
179
 
180
+ ```ruby
181
+ ApplicationRecord.dynamic_preload(comments, [:votes])
182
+ ```
183
+
178
184
  <details>
179
185
  <summary>example usage</summary>
180
186
  Preload :votes on some comments. :votes is an active record has_many relation.
@@ -184,7 +190,7 @@ Preload :votes on some comments. :votes is an active record has_many relation.
184
190
  SELECT * FROM comments LIMIT 4
185
191
  })
186
192
  comments.class.to_s # 'Array' note: not a relation.
187
- ApplicationRecord.headache_preload(comments, [:votes])
193
+ ApplicationRecord.dynamic_preload(comments, [:votes])
188
194
  puts comments[0].votes #this line should be preloaded and hence not call the database
189
195
 
190
196
  #note that this above is basically the same as doing the below assuming there is a comments relation on the user model.
@@ -199,6 +205,10 @@ good during enum migrations as the code to migrate wont run if enumerate is ther
199
205
  as it is not yet enumerated (causing an error when it loads the class that will have the
200
206
  enumeration in it). This can lead it to being impossible to commit clean code.
201
207
 
208
+ ```ruby
209
+ ApplicationRecord.has_run_migration?('UserImageRelationsTwo')
210
+ ```
211
+
202
212
  <details><summary>example usage</summary>
203
213
  only load relationa if it exists in the database
204
214
 
@@ -219,6 +229,10 @@ end
219
229
 
220
230
  accepts a list of association names, checks if the model has those associations
221
231
 
232
+ ```ruby
233
+ obj.has_association?(:votes)
234
+ ```
235
+
222
236
  <details><summary>example usage</summary>
223
237
  Check if object is a votable class
224
238
 
@@ -230,19 +244,27 @@ obj.has_association?(:votes) #false
230
244
  ```
231
245
  </details>
232
246
 
233
- #### self.dynamic_instaload_sql(name, insta_array, opts = { })
247
+ #### self.dynamic_instaload_sql( *optional* name, insta_array, opts = { })
234
248
  *instaloads* a bunch of diffrent models at the same time by casting them to json before returning them. Kinda cool. Maybe a bit overcomplicated. Seems to be more efficient to preloading when i tested it.
235
249
  - name is passed to dynamic_sql and is the name of the sql request
236
250
  - opts are passed to dynamic_sql (except for the raw option which is set to true. Raw output is not allowed on this request)
237
251
  - requires a list of instaload method output which provides information for how to treat each sql block.
238
-
252
+
253
+ ```ruby
254
+ out = ApplicationRecord.instaload_sql([
255
+ ApplicationRecord.instaload("SELECT id FROM users", relied_on: true, dont_return: true, table_name: "users_2"),
256
+ ApplicationRecord.instaload("SELECT id FROM users_2 WHERE id % 2 != 0 LIMIT :limit", table_name: 'a'),
257
+ User.instaload("SELECT id FROM users_2 WHERE id % 2 != 1 LIMIT :limit", table_name: 'b')
258
+ ], limit: 2)
259
+ ```
260
+
239
261
  <details>
240
262
  <summary>example usage</summary>
241
263
  #get list of users, those users friends, and who those users follow, all in one request.
242
264
 
243
265
  ```ruby
244
266
  # the ruby entered
245
- output = ApplicationRecord.dynamic_instaload_sql('test', [
267
+ output = ApplicationRecord.dynamic_instaload_sql([
246
268
  User.instaload('SELECT id FROM users WHERE users.id = ANY (:user_ids) AND users.created_at > :time', table_name: 'limited_users', relied_on: true),
247
269
  User.instaload(%Q{
248
270
  SELECT friends.smaller_user_id AS id, friends.bigger_user_id AS friended_to
@@ -297,8 +319,6 @@ the output:
297
319
  {"followable_id"=>932, "follower_id"=>23},
298
320
  {"followable_id"=>935, "follower_id"=>19},
299
321
  ...]}
300
-
301
-
302
322
  ```
303
323
  </details>
304
324
 
@@ -1,5 +1,5 @@
1
1
 
2
2
  module DynamicRecordsMeritfront
3
- VERSION = '3.0.1'
3
+ VERSION = '3.0.3'
4
4
  end
5
5
  #this file gets overwritten automatically on minor updates, major ones need to be manually changed
metadata CHANGED
@@ -1,7 +1,7 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: dynamic-records-meritfront
3
3
  version: !ruby/object:Gem::Version
4
- version: 3.0.1
4
+ version: 3.0.3
5
5
  platform: ruby
6
6
  authors:
7
7
  - Luke Clancy