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 +4 -4
- data/Gemfile.lock +1 -1
- data/README.md +31 -26
- data/lib/dynamic-records-meritfront/version.rb +1 -1
- data/lib/dynamic-records-meritfront.rb +2 -2
- metadata +2 -2
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA256:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 4d7119a7be4c9ab826096a83190f68aa1d069e7db36f03ddeade1665788fc449
|
4
|
+
data.tar.gz: 21e633fc3369067d1e6bd9090e83a2f241d6efacd2bb63f4c6d06cba0bf85e5f
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 330b3763f9c3387313f2142fe039e93fd36cca3a0736563f832b929640f6286fc3f03f3dde6dfa6b9e28ad52b576d14bab2eefc0525bc5fae712673f7069f4b5
|
7
|
+
data.tar.gz: e05da4103fe1fed2942963bf898f4a0994fa75a9fd2ddcf7cf9c4b2a3aa0cf78baed5c42c39fcdba43e2fa949850160a591da2ba092cfc41b62f873ef2f51848
|
data/Gemfile.lock
CHANGED
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
|
@@ -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
|
-
|
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.
|
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-
|
11
|
+
date: 2022-10-17 00:00:00.000000000 Z
|
12
12
|
dependencies:
|
13
13
|
- !ruby/object:Gem::Dependency
|
14
14
|
name: hashid-rails
|