dynamic-records-meritfront 3.0.1 → 3.0.6

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 6a2496e72da8096b231edb9fab7d9a469926bbcd9a698d0224a78ee7ed5e25a5
-  data.tar.gz: 23100e7e24dad43bdfeab2f1291d4616c72e3726eba69a1c3cb2be99cf73df19
+  metadata.gz: aa816c1fc2d4e08950ff1f91c1bb4aa1d8025a4e845d62919e7254e449a6901f
+  data.tar.gz: 4649ad599b97346ca16ddbb5f07298fd0408d5028795fcfcb3e5f0b5d1f906c9
 SHA512:
-  metadata.gz: a2861fed694119175940f5153f429491cc25210611da866e55b5a52720610655a89b8291dd7bf1a1042fa155ce8c7dbeacbb846470e01645dda9381d868c6b42
-  data.tar.gz: 84110301448a31b997b6acbd89b99dfbe3d5b3c6432e7ba7cafc20b78bfa92a80818a4291da6a30090643fc7eec3da2028f8a30030339e0ac7cdd90f7c12d49a
+  metadata.gz: 2dbba9dee9ca11dab5665b0d96a2b13840f7bfff8eb28c859e8628119efb420924435ed06ca380dc9fec7408231cf7a7f9671429cc34c18c2e0536646324a3ba
+  data.tar.gz: cddf05b9c1f9eb9df8c1c7fb1a586dc618eed8a5f3fd0a0b8f8b4017d3bbb0beee66143c4925bd102af52d2ea6e302c5fda7384ca8c4f7cfafa8b481afefc0f8

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    dynamic-records-meritfront (3.0.1)
+    dynamic-records-meritfront (3.0.6)
       hashid-rails
 
 GEM

data/README.md

@@ -11,14 +11,12 @@ Note that postgres is currently a requirement for this gem.
 ```ruby
 # returns a json-like hash list of user data
 users = ApplicationRecord.dynamic_sql(
-	'get_5_users',
 	'select * from users limit :our_limit',
 	our_limit: 5
 )
 
 #returns a list of users (each an instance of User)
 users = User.dynamic_sql(
-	'get_users_from_ids',
 	'select * from users where id = ANY (:ids)',
 	ids: [1,2,3]
 )
@@ -53,28 +51,34 @@ Or install it yourself as:
 class ApplicationRecord < ActiveRecord::Base
 	self.abstract_class = true
 	include DynamicRecordsMeritfront
-	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.
+	
+	#DYNAMIC_SQL_RAW determines whether dynamic_sql method returns a ActiveRecord::Response object or an Array.
+	#They both have pros and cons. False returns the array.
+	DynamicRecordsMeritfront::DYNAMIC_SQL_RAW = false
 end
 ```
 
 ### SQL methods
 
-These are methods written for easier sql usage.
+Methods written for easier sql usage.
 
-#### self.dynamic_sql(name, sql, opts = { })
+#### self.dynamic_sql( *optional* name, sql, opts = { })
 A better and safer way to write sql. Can return either a Hash, ActiveRecord::Response object, or an instantiated model.
 
+```ruby
+User.dynamic_sql('select * from users')	#returns all users
+ApplicationRecord.dynamic_sql('select * from users') #returns all user column information in an array
+```
+
 with options: 
 - 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.
 - 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.
-- 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.
 
-other options:
+other less critical options:
 
 - 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.
-- name_modifiers: allows one to change the associated name dynamically.
 - multi_query: allows more than one query (you can seperate an insert and an update with ';' I dont know how else to say it.)
-    this disables other options including arguments (except name_modifiers). Not sure how it effects prepared statements. Not super useful.
+    this disables other options including sql_arguments. Not sure how it effects prepared statements. Not super useful.
 - 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?
 	
 <details>
@@ -91,7 +95,7 @@ Delete Friend Requests between two users after they have become friends.
 </details>
 
 <details>
-<summary>dynamic sql example usage</summary>
+<summary>example usage with interpreted sql string</summary>
 Get all users who have made a friend request to a particular user with an optional limit.
 This is an example of why this method is good for dynamic prepared statements.
 
@@ -106,9 +110,7 @@ This is an example of why this method is good for dynamic prepared statements.
         ) AS all_friend_requests
         ORDER BY all_friend_requests.created_at DESC
         #{"LIMIT :limit" if limit > 0}
-    }, uid: u, limit: limit, name_modifiers: [
-        limit > 0 ? 'limited' : nil
-    ])
+    }, uid: u, limit: limit)
 ```
 </details>
 	
@@ -117,13 +119,13 @@ This is an example of why this method is good for dynamic prepared statements.
 
 ```ruby
     #get a normal test vote
-    test =  Vote.dynamic_sql('test', %Q{
+    test =  Vote.dynamic_sql(%Q{
         SELECT id FROM votes LIMIT 1
     }).first
     v.inspect 	#   "#<Vote id: 696969>"
 
     #get a cool test vote. Note that is_this_vote_cool is not on the vote table.
-    test =  Vote.dynamic_sql('test', %Q{
+    test =  Vote.dynamic_sql(%Q{
         SELECT id, 'yes' AS is_this_vote_cool FROM votes LIMIT 1
     }).first
    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.
@@ -147,27 +149,28 @@ Get users who match a list of ids. Uses a postgresql Array, see the potential is
 Do an upsert
 
 ```ruby
+	time = DateTime.now
 	rows = uzrs.map{|u| [
 		u.id,		#user_id
 		self.id,	#conversation_id
 		from,		#invited_by
-		t,		#created_at
-		t,		#updated_at
+		:time,		#created_at		(We use symbols to denote other sql arguments)
+		:time,		#updated_at
 	]}
 	ApplicationRecord.dynamic_sql("upsert_conversation_invites_2", %Q{
 		INSERT INTO conversation_participants (user_id, conversation_id, invited_by, created_at, updated_at)
 		VALUES :rows
 		ON CONFLICT (conversation_id,user_id)
 		DO UPDATE SET updated_at = :time
-	}, rows: rows, time: t)
+	}, rows: rows, time: time)
 ```
-This will output sql similar to below. Note this can be done for multiple conversation_participants. Also note that it only sent one time variable as an argument as dynamic_sql detected that we were sending duplicate information.
+This will output sql similar to below. Note this can be done for multiple conversation_participants. Also note that we sent only one time variable during our request instead of duplicating it.
 ```sql
 	INSERT INTO conversation_participants (user_id, conversation_id, invited_by, created_at, updated_at)
 	VALUES ($1,$2,$3,$4,$4)
 	ON CONFLICT (conversation_id,user_id)
 	DO UPDATE SET updated_at = $4
-	-- [["rows_1", 15], ["rows_2", 67], ["rows_3", 6], ["rows_4", "2022-10-13 20:49:27.441372"]]
+	-- [["rows_1", 15], ["rows_2", 67], ["rows_3", 6], [:time, "2022-10-13 20:49:27.441372"]]
 ```
 </details>
 	
@@ -175,6 +178,10 @@ This will output sql similar to below. Note this can be done for multiple conver
 #### self.dynamic_preload(records, associations)
 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. 
 
+```ruby
+ApplicationRecord.dynamic_preload(comments, [:votes])
+```
+
 <details>
 <summary>example usage</summary>
 Preload :votes on some comments. :votes is an active record has_many relation.
@@ -184,7 +191,7 @@ Preload :votes on some comments. :votes is an active record has_many relation.
         SELECT * FROM comments LIMIT 4
     })
     comments.class.to_s # 'Array' note: not a relation.
-    ApplicationRecord.headache_preload(comments, [:votes])
+    ApplicationRecord.dynamic_preload(comments, [:votes])
     puts comments[0].votes #this line should be preloaded and hence not call the database
 
     #note that this above is basically the same as doing the below assuming there is a comments relation on the user model.
@@ -199,6 +206,10 @@ good during enum migrations as the code to migrate wont run if enumerate is ther
 as it is not yet enumerated (causing an error when it loads the class that will have the
 enumeration in it). This can lead it to being impossible to commit clean code.
 
+```ruby
+ApplicationRecord.has_run_migration?('UserImageRelationsTwo')
+```
+
 <details><summary>example usage</summary>
 only load relationa if it exists in the database
 
@@ -219,6 +230,10 @@ end
 
 accepts a list of association names, checks if the model has those associations
 
+```ruby
+obj.has_association?(:votes)
+```
+
 <details><summary>example usage</summary>
 Check if object is a votable class
 
@@ -230,19 +245,27 @@ obj.has_association?(:votes) #false
 ```
 </details>
 
-#### self.dynamic_instaload_sql(name, insta_array, opts = { })
+#### self.instaload_sql( *optional* name, insta_array, opts = { })
 *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.
 - name is passed to dynamic_sql and is the name of the sql request
 - opts are passed to dynamic_sql (except for the raw option which is set to true. Raw output is not allowed on this request)
 - requires a list of instaload method output which provides information for how to treat each sql block.
-	
+
+```ruby
+out = ApplicationRecord.instaload_sql([
+	ApplicationRecord.instaload("SELECT id FROM users", relied_on: true, dont_return: true, table_name: "users_2"),
+	ApplicationRecord.instaload("SELECT id FROM users_2 WHERE id % 2 != 0 LIMIT :limit", table_name: 'a'),
+	User.instaload("SELECT id FROM users_2 WHERE id % 2 != 1 LIMIT :limit", table_name: 'b')
+], limit: 2)
+```
+
 <details>
 <summary>example usage</summary>
 #get list of users, those users friends, and who those users follow, all in one request.
 
 ```ruby
    # the ruby entered
-   output = ApplicationRecord.dynamic_instaload_sql('test', [
+   output = ApplicationRecord.instaload_sql([
       User.instaload('SELECT id FROM users WHERE users.id = ANY (:user_ids) AND users.created_at > :time', table_name: 'limited_users', relied_on: true),
       User.instaload(%Q{
          SELECT friends.smaller_user_id AS id, friends.bigger_user_id AS friended_to
@@ -297,13 +320,11 @@ the output:
    {"followable_id"=>932, "follower_id"=>23},
    {"followable_id"=>935, "follower_id"=>19},
    ...]}
-
-
 ```
 </details>
 	
 #### self.instaload(sql, table_name: nil, relied_on: false, dont_return: false)
-A method used to prepare data for the dynamic_instaload_sql method. It returns a hash of options.
+A method used to prepare data for the instaload_sql method. It returns a hash of options.
 - klass called on: if called on an abstract class (ApplicationRecord) it will return a list of hashes with the data. Otherwise returns a list of the classes records.
 - table_name: sets the name of the temporary postgresql table. This can then be used in further instaload sql snippets.
 - relied_on: will make it so other instaload sql snippets can reference this table (it makes it use posrgresql's WITH operator)
@@ -329,7 +350,7 @@ User.instaload('SELECT id FROM users WHERE users.id = ANY (:user_ids) AND users.
 </details>
 
 #### self.dynamic_attach(instaload_sql_output, base_name, attach_name, base_on: nil, attach_on: nil, one_to_one: false)
-taking the output of the dynamic_instaload_sql, this method attaches the models together so they are attached.
+taking the output of the instaload_sql method, this method creates relations between the models.
 - base_name: the name of the table we will be attaching to
 - attach_name: the name of the table that will be attached
 - base_on: put a proc here to override the matching key for the base table. Default is, for a user and post type, {|user| user.id}
@@ -337,7 +358,7 @@ taking the output of the dynamic_instaload_sql, this method attaches the models
 - one_to_one: switches between a one-to-one relationship or not
 
 <details> 
-<summary> attach information for each limited_user in the dynamic_instaload_sql example </summary>
+<summary> attach information for each limited_user in the instaload_sql example </summary>
 	
 ```ruby
 	

data/lib/dynamic-records-meritfront/version.rb

@@ -1,5 +1,5 @@
 
 	module DynamicRecordsMeritfront
-	    VERSION = '3.0.1'
+	    VERSION = '3.0.6'
 	end
 	#this file gets overwritten automatically on minor updates, major ones need to be manually changed

data/lib/dynamic-records-meritfront.rb

@@ -17,7 +17,7 @@ module DynamicRecordsMeritfront
 		#should work, probably able to override by redefining in ApplicationRecord class.
 		#Note we defined here as it breaks early on as Rails.application returns nil
 		PROJECT_NAME = Rails.application.class.to_s.split("::").first.to_s.downcase
-        DYNAMIC_SQL_RAW = false
+        DYNAMIC_SQL_RAW = true
 	end
     class DynamicSqlVariables
         attr_accessor :sql_hash

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: dynamic-records-meritfront
 version: !ruby/object:Gem::Version
-  version: 3.0.1
+  version: 3.0.6
 platform: ruby
 authors:
 - Luke Clancy
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2022-12-12 00:00:00.000000000 Z
+date: 2022-12-14 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: hashid-rails