graphile-build-pg - npm Package Compare versions

Comparing version 0.1.0-alpha.15 to 0.1.0-alpha.16

node7minus/plugins/viaTemporaryTable.js

@@ -7,2 +7,6 @@ "use strict";
 
+var _keys = require("babel-runtime/core-js/object/keys");
+
+var _keys2 = _interopRequireDefault(_keys);
+
 var _regenerator = require("babel-runtime/regenerator");
@@ -29,25 +33,30 @@
 /*
-   * Originally we tried this with a CTE, but:
-   *
-   * > The sub-statements in WITH are executed concurrently
-   * > with each other and with the main query. Therefore, when
-   * > using data-modifying statements in WITH, the order in
-   * > which the specified updates actually happen is
-   * > unpredictable. All the statements are executed with the
-   * > same snapshot (see Chapter 13), so they cannot "see" one
-   * > another's effects on the target tables. This alleviates
-   * > the effects of the unpredictability of the actual order
-   * > of row updates, and means that RETURNING data is the only
-   * > way to communicate changes between different WITH
-   * > sub-statements and the main query.
-   *
-   * -- https://www.postgresql.org/docs/9.6/static/queries-with.html
-   *
-   * This caused issues with computed columns that themselves
-   * went off and performed selects - because the data within
-   * those selects used the old snapshot and thus returned
-   * stale data. To solve this, we now use temporary tables to
-   * ensure the mutation and the select execute in different
-   * statments.
-   */
+ * Originally we tried this with a CTE, but:
+ *
+ * > The sub-statements in WITH are executed concurrently with each other and
+ * > with the main query. Therefore, when using data-modifying statements in
+ * > WITH, the order in which the specified updates actually happen is
+ * > unpredictable. All the statements are executed with the same snapshot (see
+ * > Chapter 13), so they cannot "see" one another's effects on the target
+ * > tables. This alleviates the effects of the unpredictability of the actual
+ * > order of row updates, and means that RETURNING data is the only way to
+ * > communicate changes between different WITH sub-statements and the main
+ * > query.
+ *
+ * -- https://www.postgresql.org/docs/9.6/static/queries-with.html
+ *
+ * This caused issues with computed columns that themselves went off and
+ * performed selects - because the data within those selects used the old
+ * snapshot and thus returned stale data.
+ *
+ * To solve this, we tried using temporary tables to ensure the mutation and
+ * the select execute in different statments. This worked, but temporary tables
+ * require elevated priviliges and thus don't work everywhere. We needed a more
+ * generic solution.
+ *
+ * In the end we settled for sending the data we received from the mutations
+ * straight back into the PostgreSQL server. It's a bit wasteful but it works.
+ *
+ * If you can come up with a better solution please open a pull request!
+ */
 
@@ -83,3 +92,5 @@ exports.default = function () {
     var isPgClassLike = arguments.length > 5 && arguments[5] !== undefined ? arguments[5] : true;
-    var sqlTemporaryTableAlias, results;
+
+    var _ref3, rows, values;
+
     return _regenerator2.default.wrap(function _callee2$(_context2) {
@@ -104,24 +115,20 @@ while (1) {
           case 6:
-            sqlTemporaryTableAlias = _pgSql2.default.identifier(`__temporary_${String(Math.random()).replace(/[^0-9]+/g, "")}__`);
-            _context2.next = 9;
+            _context2.next = 8;
             return performQuery(pgClient, _pgSql2.default.query`
-      create temporary table ${sqlTemporaryTableAlias} (
-        id serial not null,
-        row ${sqlTypeIdentifier}
-      ) on commit drop`);
-
-          case 9:
-            _context2.next = 11;
-            return performQuery(pgClient, _pgSql2.default.query`
       with ${sqlResultSourceAlias} as (
         ${sqlMutationQuery}
       )
-      insert into ${sqlTemporaryTableAlias} (row)
       select ${isPgClassLike ? sqlResultSourceAlias : _pgSql2.default.query`${sqlResultSourceAlias}.${sqlResultSourceAlias}`}::${sqlTypeIdentifier} from ${sqlResultSourceAlias}`);
 
-          case 11:
+          case 8:
+            _ref3 = _context2.sent;
+            rows = _ref3.rows;
+            values = rows.map(function (row) {
+              return row[(0, _keys2.default)(row)[0]];
+            });
             _context2.next = 13;
             return performQuery(pgClient, _pgSql2.default.query`
       with ${sqlResultSourceAlias} as (
-        select ${isPgClassLike ? _pgSql2.default.query`(${sqlTemporaryTableAlias}.row).*` : _pgSql2.default.query`${sqlTemporaryTableAlias}.row as ${sqlResultSourceAlias}`} from ${sqlTemporaryTableAlias} order by id asc
+        select ${isPgClassLike ? _pgSql2.default.query`(str::${sqlTypeIdentifier}).*` : _pgSql2.default.query`str::${sqlTypeIdentifier} as ${sqlResultSourceAlias}`}
+        from unnest((${_pgSql2.default.value(values)})::${sqlTypeIdentifier}[]) str
       )
@@ -131,10 +138,5 @@ ${sqlResultQuery}`);
           case 13:
-            results = _context2.sent;
-            _context2.next = 16;
-            return performQuery(pgClient, _pgSql2.default.query`drop table ${sqlTemporaryTableAlias};`);
+            return _context2.abrupt("return", _context2.sent);
 
-          case 16:
-            return _context2.abrupt("return", results);
-
-          case 17:
+          case 14:
           case "end":
@@ -141,0 +143,0 @@ return _context2.stop();

node8plus/plugins/viaTemporaryTable.js

@@ -7,2 +7,6 @@ "use strict";
 
+var _keys = require("babel-runtime/core-js/object/keys");
+
+var _keys2 = _interopRequireDefault(_keys);
+
 var _pgSql = require("pg-sql2");
@@ -21,25 +25,30 @@
 /*
-   * Originally we tried this with a CTE, but:
-   *
-   * > The sub-statements in WITH are executed concurrently
-   * > with each other and with the main query. Therefore, when
-   * > using data-modifying statements in WITH, the order in
-   * > which the specified updates actually happen is
-   * > unpredictable. All the statements are executed with the
-   * > same snapshot (see Chapter 13), so they cannot "see" one
-   * > another's effects on the target tables. This alleviates
-   * > the effects of the unpredictability of the actual order
-   * > of row updates, and means that RETURNING data is the only
-   * > way to communicate changes between different WITH
-   * > sub-statements and the main query.
-   *
-   * -- https://www.postgresql.org/docs/9.6/static/queries-with.html
-   *
-   * This caused issues with computed columns that themselves
-   * went off and performed selects - because the data within
-   * those selects used the old snapshot and thus returned
-   * stale data. To solve this, we now use temporary tables to
-   * ensure the mutation and the select execute in different
-   * statments.
-   */
+ * Originally we tried this with a CTE, but:
+ *
+ * > The sub-statements in WITH are executed concurrently with each other and
+ * > with the main query. Therefore, when using data-modifying statements in
+ * > WITH, the order in which the specified updates actually happen is
+ * > unpredictable. All the statements are executed with the same snapshot (see
+ * > Chapter 13), so they cannot "see" one another's effects on the target
+ * > tables. This alleviates the effects of the unpredictability of the actual
+ * > order of row updates, and means that RETURNING data is the only way to
+ * > communicate changes between different WITH sub-statements and the main
+ * > query.
+ *
+ * -- https://www.postgresql.org/docs/9.6/static/queries-with.html
+ *
+ * This caused issues with computed columns that themselves went off and
+ * performed selects - because the data within those selects used the old
+ * snapshot and thus returned stale data.
+ *
+ * To solve this, we tried using temporary tables to ensure the mutation and
+ * the select execute in different statments. This worked, but temporary tables
+ * require elevated priviliges and thus don't work everywhere. We needed a more
+ * generic solution.
+ *
+ * In the end we settled for sending the data we received from the mutations
+ * straight back into the PostgreSQL server. It's a bit wasteful but it works.
+ *
+ * If you can come up with a better solution please open a pull request!
+ */
 
@@ -60,25 +69,16 @@ exports.default = async function viaTemporaryTable(pgClient, sqlTypeIdentifier, sqlMutationQuery, sqlResultSourceAlias, sqlResultQuery, isPgClassLike = true) {
   } else {
-    const sqlTemporaryTableAlias = _pgSql2.default.identifier(`__temporary_${String(Math.random()).replace(/[^0-9]+/g, "")}__`);
-
-    await performQuery(pgClient, _pgSql2.default.query`
-      create temporary table ${sqlTemporaryTableAlias} (
-        id serial not null,
-        row ${sqlTypeIdentifier}
-      ) on commit drop`);
-
-    await performQuery(pgClient, _pgSql2.default.query`
+    const { rows } = await performQuery(pgClient, _pgSql2.default.query`
       with ${sqlResultSourceAlias} as (
         ${sqlMutationQuery}
       )
-      insert into ${sqlTemporaryTableAlias} (row)
       select ${isPgClassLike ? sqlResultSourceAlias : _pgSql2.default.query`${sqlResultSourceAlias}.${sqlResultSourceAlias}`}::${sqlTypeIdentifier} from ${sqlResultSourceAlias}`);
-    const results = await performQuery(pgClient, _pgSql2.default.query`
+    const values = rows.map(row => row[(0, _keys2.default)(row)[0]]);
+    return await performQuery(pgClient, _pgSql2.default.query`
       with ${sqlResultSourceAlias} as (
-        select ${isPgClassLike ? _pgSql2.default.query`(${sqlTemporaryTableAlias}.row).*` : _pgSql2.default.query`${sqlTemporaryTableAlias}.row as ${sqlResultSourceAlias}`} from ${sqlTemporaryTableAlias} order by id asc
+        select ${isPgClassLike ? _pgSql2.default.query`(str::${sqlTypeIdentifier}).*` : _pgSql2.default.query`str::${sqlTypeIdentifier} as ${sqlResultSourceAlias}`}
+        from unnest((${_pgSql2.default.value(values)})::${sqlTypeIdentifier}[]) str
       )
       ${sqlResultQuery}`);
-    await performQuery(pgClient, _pgSql2.default.query`drop table ${sqlTemporaryTableAlias};`);
-    return results;
   }
 };
 //# sourceMappingURL=viaTemporaryTable.js.map

package.json

 {
   "name": "graphile-build-pg",
-  "version": "0.1.0-alpha.15",
+  "version": "0.1.0-alpha.16",
   "description": "Build a GraphQL schema by reflection over a PostgreSQL schema. Easy to customize since it's built with plugins on graphile-build",
@@ -46,3 +46,3 @@ "main": "index.js",
     "pg-range-parser": "^1.0.0",
-    "pg-sql2": "1.0.0-alpha1.4",
+    "pg-sql2": "^1.0.0-beta.1",
     "pluralize": "^5.0.0"
@@ -49,0 +49,0 @@ },

New alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Fixed alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Worsened metrics

Total package byte prevSize

1292276

decreased by-0.06%

Dependency changes

• + Addedpg-sql2@1.0.0-beta.8(transitive)

• - Removedpg-sql2@1.0.0-alpha1.4(transitive)

• Updatedpg-sql2@^1.0.0-beta.1