dynamic-records-meritfront 1.1.10 → 1.1.11

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: 549b1d707e2419d0444845f8c15cd1564572c0ca68a72bf208a39be116feb5f3
4
- data.tar.gz: 5641ddc311be64741db802cc638b73b586be91d30edcdc171fc04949b3f57542
3
+ metadata.gz: 4d7119a7be4c9ab826096a83190f68aa1d069e7db36f03ddeade1665788fc449
4
+ data.tar.gz: 21e633fc3369067d1e6bd9090e83a2f241d6efacd2bb63f4c6d06cba0bf85e5f
5
5
  SHA512:
6
- metadata.gz: dc0a7c85bbb2ca8cdfd931c5ae9002c319809658d1437f68d3c4356758d71a5db7e277e2bcb87caa37b44608f13bc7a1c0fd38ad0e2aeb7bcc4de3a262519e28
7
- data.tar.gz: ce81fa5af8b092b10be95b3134b37051a321df53434220bca3ebbb9815b260f3fcba698891282eba179f04c22090466251c0d5a3f3e1e48d6e903b75e5197ce7
6
+ metadata.gz: 330b3763f9c3387313f2142fe039e93fd36cca3a0736563f832b929640f6286fc3f03f3dde6dfa6b9e28ad52b576d14bab2eefc0525bc5fae712673f7069f4b5
7
+ data.tar.gz: e05da4103fe1fed2942963bf898f4a0994fa75a9fd2ddcf7cf9c4b2a3aa0cf78baed5c42c39fcdba43e2fa949850160a591da2ba092cfc41b62f873ef2f51848
data/Gemfile.lock CHANGED
@@ -1,7 +1,7 @@
1
1
  PATH
2
2
  remote: .
3
3
  specs:
4
- dynamic-records-meritfront (1.1.10)
4
+ dynamic-records-meritfront (1.1.11)
5
5
  hashid-rails
6
6
 
7
7
  GEM
data/README.md CHANGED
@@ -33,31 +33,6 @@ class ApplicationRecord < ActiveRecord::Base
33
33
  end
34
34
  ```
35
35
 
36
- ### Hashed Global IDS
37
-
38
- hashed global ids look like this: "gid://meritfront/User/K9YI4K". They also have an optional tag so it can also look like "gid://meritfront/User/K9YI4K@user_image". They are based on global ids.
39
-
40
- I have been using hgids (Hashed Global IDs) for a while now and they have some unique benefits in front-end back-end communication. This is as they:
41
- 1. hash the id which is good practice
42
- 2. provide a way to have tags, this is good when updating different UI elements dynamically from the backend. For instance updating the @user_image without affecting the @user_name
43
- 3. Carry the class with them, this can allow for more abstract and efficient code, and prevents id collisions between diffrent classes.
44
-
45
- #### methods from the hashid-rails gem
46
-
47
- See the hashid-rails gem for more (https://github.com/jcypret/hashid-rails). Also note that I aliased .hashid to .hid and .find_by_hashid to .hfind
48
-
49
- #### methods from this gem
50
-
51
- 1. hgid(tag: nil) - get the hgid with optional tag. Aliased to ghid
52
- 2. hgid_as_selector(str, attribute: 'id') - get a css selector for the hgid, good for updating the front-end (especially over cable-ready and morphdom operations)
53
- 3. self.locate_hgid(hgid_string, with_associations: nil, returns_nil: false) - locates the database record from a hgid. Here are some examples of usage:
54
- - ApplicationRecord.locate_hgid(hgid) - <b>DANGEROUS</b> will return any object referenced by the hgid.
55
- - User.locate_hgid(hgid) - locates the User record but only if the hgid references a user class. Fires an error if not.
56
- - ApplicationRecord.locate_hgid(hgid, with_associations: [:votes]) - locates the record but only if the record's class has a :votes active record association. So for instance, you can accept only votable objects for upvote functionality. Fires an error if the hgid does not match.
57
- - User.locate_hgid(hgid, returns_nil: true) - locates the hgid but only if it is the user class. Returns nil if not.
58
- 4. get_hgid_tag(hgid) - returns the tag attached to the hgid
59
- 5. self.blind_hgid(id, tag) - creates a hgid without bringing the object down from the database. Useful with hashid-rails encode_id and decode_id methods
60
-
61
36
  ### SQL methods
62
37
 
63
38
  These are methods written for easier sql usage.
@@ -101,6 +76,7 @@ obj.has_association?(:votes) #false
101
76
  </details>
102
77
 
103
78
  #### self.headache_sql(name, sql, opts = { })
79
+ A better and safer way to write sql.
104
80
  with options:
105
81
  - instantiate_class: returns User, Post, etc objects instead of straight sql output.
106
82
  I prefer doing the alterantive
@@ -109,7 +85,7 @@ with options:
109
85
  - prepare: sets whether the db will preprocess the strategy for lookup (defaults true) (have not verified the prepared-ness)
110
86
  - name_modifiers: allows one to change the preprocess associated name, useful in cases of dynamic sql.
111
87
  - multi_query: allows more than one query (you can seperate an insert and an update with ';' I dont know how else to say it.)
112
- this disables other options (except name_modifiers). Not sure how it effects prepared statements.
88
+ this disables other options including arguments (except name_modifiers). Not sure how it effects prepared statements.
113
89
  - async: 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?
114
90
  - other options: considered sql arguments
115
91
 
@@ -205,6 +181,31 @@ Preload :votes on some comments. :votes is an active record has_many relation.
205
181
  puts comments[0].votes #this line should be preloaded and hence not call the database
206
182
  ```
207
183
  </details>
184
+
185
+ ### Hashed Global IDS
186
+
187
+ hashed global ids look like this: "gid://meritfront/User/K9YI4K". They also have an optional tag so it can also look like "gid://meritfront/User/K9YI4K@user_image". They are based on global ids.
188
+
189
+ I have been using hgids (Hashed Global IDs) for a while now and they have some unique benefits in front-end back-end communication. This is as they:
190
+ 1. hash the id which is good practice
191
+ 2. provide a way to have tags, this is good when updating different UI elements dynamically from the backend. For instance updating the @user_image without affecting the @user_name
192
+ 3. Carry the class with them, this can allow for more abstract and efficient code, and prevents id collisions between diffrent classes.
193
+
194
+ #### methods from the hashid-rails gem
195
+
196
+ See the hashid-rails gem for more (https://github.com/jcypret/hashid-rails). Also note that I aliased .hashid to .hid and .find_by_hashid to .hfind
197
+
198
+ #### methods from this gem
199
+
200
+ 1. hgid(tag: nil) - get the hgid with optional tag. Aliased to ghid
201
+ 2. hgid_as_selector(str, attribute: 'id') - get a css selector for the hgid, good for updating the front-end (especially over cable-ready and morphdom operations)
202
+ 3. self.locate_hgid(hgid_string, with_associations: nil, returns_nil: false) - locates the database record from a hgid. Here are some examples of usage:
203
+ - ApplicationRecord.locate_hgid(hgid) - <b>DANGEROUS</b> will return any object referenced by the hgid.
204
+ - User.locate_hgid(hgid) - locates the User record but only if the hgid references a user class. Fires an error if not.
205
+ - ApplicationRecord.locate_hgid(hgid, with_associations: [:votes]) - locates the record but only if the record's class has a :votes active record association. So for instance, you can accept only votable objects for upvote functionality. Fires an error if the hgid does not match.
206
+ - User.locate_hgid(hgid, returns_nil: true) - locates the hgid but only if it is the user class. Returns nil if not.
207
+ 4. get_hgid_tag(hgid) - returns the tag attached to the hgid
208
+ 5. self.blind_hgid(id, tag) - creates a hgid without bringing the object down from the database. Useful with hashid-rails encode_id and decode_id methods
208
209
 
209
210
  ## Potential Issues
210
211
 
@@ -212,6 +213,10 @@ This gem was made with a postgresql database. Although most of the headache_sql
212
213
 
213
214
  Let me know if this actually becomes an issue for someone and I will throw in a workaround.
214
215
 
216
+ ## Next Up
217
+ - I have the beginnings of something called swiss_instaload in mind, which will load multiple tables at the same time. For instance instead of Doing a ```usrs = User.all``` combined with a ```usrs.preload(:votes)```, which takes two sql requests, it could be done in one. Its kind of a crazy and dubious idea (efficiency wise), but I have a working prototype. It works by casting everything to json before returning it from the database. There might be a better way to do that long term though.
218
+ - will be changing names from headache_* which is a bit negative to swiss_* as in swiss_army_knife which is known for its wide versitility. headache names will become aliases.
219
+
215
220
  ## Changelog
216
221
 
217
222
  1.1.10
@@ -1,5 +1,5 @@
1
1
 
2
2
  module DynamicRecordsMeritfront
3
- VERSION = '1.1.10'
3
+ VERSION = '1.1.11'
4
4
  end
5
5
  #this file gets overwritten automatically on minor updates, major ones need to be manually changed
@@ -133,10 +133,10 @@ module DynamicRecordsMeritfront
133
133
  (args.length == (associations & args).length)
134
134
  end
135
135
 
136
- def blind_hgid(id, tag: nil)
136
+ def blind_hgid(id, tag: nil, encode: true)
137
137
  # this method is to get an hgid for a class without actually calling it down from the database.
138
138
  # For example Notification.blind_hgid 1 will give gid://PROJECT_NAME/Notification/69DAB69 etc.
139
- unless id.class == String
139
+ if id.class == Integer and encode
140
140
  id = self.encode_id id
141
141
  end
142
142
  gid = "gid://#{PROJECT_NAME}/#{self.to_s}/#{id}"
metadata CHANGED
@@ -1,14 +1,14 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: dynamic-records-meritfront
3
3
  version: !ruby/object:Gem::Version
4
- version: 1.1.10
4
+ version: 1.1.11
5
5
  platform: ruby
6
6
  authors:
7
7
  - Luke Clancy
8
8
  autorequire:
9
9
  bindir: exe
10
10
  cert_chain: []
11
- date: 2022-10-13 00:00:00.000000000 Z
11
+ date: 2022-10-17 00:00:00.000000000 Z
12
12
  dependencies:
13
13
  - !ruby/object:Gem::Dependency
14
14
  name: hashid-rails