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 +4 -4
- data/Gemfile.lock +1 -1
- data/README.md +41 -21
- data/lib/dynamic-records-meritfront/version.rb +1 -1
- metadata +1 -1
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA256:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 15173d17ad833e673910fc87f1dd1c6801105086f9a36e2042154c3e624fbc50
|
4
|
+
data.tar.gz: 171e89a86eef3b0f75a92a75b4226ab401eda42ad9dd83bb4bed16b92ae439db
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 20cae9b9c791929d29002d171a837291c1e9315dc9bbb6b4a408212dd98ce408aae270a1b52caeb91f73995ac086e4ff9afd771b9a2a51878bea400881141c88
|
7
|
+
data.tar.gz: 551ef2074974ae385c9759ac58c2c170faeb835ed87ca166d7ccfe38779b6f2d03d2f3a3fc06c53e3a05c38a93ccf014a240f13a7b78eb227810d8fcc5928151
|
data/Gemfile.lock
CHANGED
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
|
-
|
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
|
-
|
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
|
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>
|
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
|
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(
|
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(
|
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.
|
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(
|
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
|
|