@webresto/graphql 1.3.1 → 1.3.4

package/test/fixture/config/sockets.js

@@ -1,141 +1,141 @@
-/**
- * WebSocket Server Settings
- * (sails.config.sockets)
- *
- * These settings provide transparent access to the options for Sails'
- * encapsulated WebSocket server, as well as some additional Sails-specific
- * configuration layered on top.
- *
- * For more information on sockets configuration, including advanced config options, see:
- * http://sailsjs.org/#!/documentation/reference/sails.config/sails.config.sockets.html
- */
-
-module.exports.sockets = {
-
-
-  /***************************************************************************
-  *                                                                          *
-  * Node.js (and consequently Sails.js) apps scale horizontally. It's a      *
-  * powerful, efficient approach, but it involves a tiny bit of planning. At *
-  * scale, you'll want to be able to copy your app onto multiple Sails.js    *
-  * servers and throw them behind a load balancer.                           *
-  *                                                                          *
-  * One of the big challenges of scaling an application is that these sorts  *
-  * of clustered deployments cannot share memory, since they are on          *
-  * physically different machines. On top of that, there is no guarantee     *
-  * that a user will "stick" with the same server between requests (whether  *
-  * HTTP or sockets), since the load balancer will route each request to the *
-  * Sails server with the most available resources. However that means that  *
-  * all room/pubsub/socket processing and shared memory has to be offloaded  *
-  * to a shared, remote messaging queue (usually Redis)                      *
-  *                                                                          *
-  * Luckily, Socket.io (and consequently Sails.js) apps support Redis for    *
-  * sockets by default. To enable a remote redis pubsub server, uncomment    *
-  * the config below.                                                        *
-  *                                                                          *
-  * Worth mentioning is that, if `adapter` config is `redis`, but host/port  *
-  * is left unset, Sails will try to connect to redis running on localhost   *
-  * via port 6379                                                            *
-  *                                                                          *
-  ***************************************************************************/
-  // adapter: 'memory',
-
-  //
-  // -OR-
-  //
-
-  // adapter: 'socket.io-redis',
-  // host: '127.0.0.1',
-  // port: 6379,
-  // db: 0,
-  // pass: '<redis auth password>',
-
-
-
- /***************************************************************************
-  *                                                                          *
-  * Whether to expose a 'get /__getcookie' route with CORS support that sets *
-  * a cookie (this is used by the sails.io.js socket client to get access to *
-  * a 3rd party cookie and to enable sessions).                              *
-  *                                                                          *
-  * Warning: Currently in this scenario, CORS settings apply to interpreted  *
-  * requests sent via a socket.io connection that used this cookie to        *
-  * connect, even for non-browser clients! (e.g. iOS apps, toasters, node.js *
-  * unit tests)                                                              *
-  *                                                                          *
-  ***************************************************************************/
-
-  // grant3rdPartyCookie: true,
-
-
-
-  /***************************************************************************
-  *                                                                          *
-  * `beforeConnect`                                                          *
-  *                                                                          *
-  * This custom beforeConnect function will be run each time BEFORE a new    *
-  * socket is allowed to connect, when the initial socket.io handshake is    *
-  * performed with the server.                                               *
-  *                                                                          *
-  * By default, when a socket tries to connect, Sails allows it, every time. *
-  * (much in the same way any HTTP request is allowed to reach your routes.  *
-  * If no valid cookie was sent, a temporary session will be created for the *
-  * connecting socket.                                                       *
-  *                                                                          *
-  * If the cookie sent as part of the connection request doesn't match any   *
-  * known user session, a new user session is created for it.                *
-  *                                                                          *
-  * In most cases, the user would already have a cookie since they loaded    *
-  * the socket.io client and the initial HTML page you're building.         *
-  *                                                                          *
-  * However, in the case of cross-domain requests, it is possible to receive *
-  * a connection upgrade request WITHOUT A COOKIE (for certain transports)   *
-  * In this case, there is no way to keep track of the requesting user       *
-  * between requests, since there is no identifying information to link      *
-  * him/her with a session. The sails.io.js client solves this by connecting *
-  * to a CORS/jsonp endpoint first to get a 3rd party cookie(fortunately this*
-  * works, even in Safari), then opening the connection.                     *
-  *                                                                          *
-  * You can also pass along a ?cookie query parameter to the upgrade url,    *
-  * which Sails will use in the absence of a proper cookie e.g. (when        *
-  * connecting from the client):                                             *
-  * io.sails.connect('http://localhost:1337?cookie=smokeybear')              *
-  *                                                                          *
-  * Finally note that the user's cookie is NOT (and will never be) accessible*
-  * from client-side javascript. Using HTTP-only cookies is crucial for your *
-  * app's security.                                                          *
-  *                                                                          *
-  ***************************************************************************/
-  // beforeConnect: function(handshake, cb) {
-  //   // `true` allows the connection
-  //   return cb(null, true);
-  //
-  //   // (`false` would reject the connection)
-  // },
-
-
-  /***************************************************************************
-  *                                                                          *
-  * `afterDisconnect`                                                        *
-  *                                                                          *
-  * This custom afterDisconnect function will be run each time a socket      *
-  * disconnects                                                              *
-  *                                                                          *
-  ***************************************************************************/
-  // afterDisconnect: function(session, socket, cb) {
-  //   // By default: do nothing.
-  //   return cb();
-  // },
-
-  /***************************************************************************
-  *                                                                          *
-  * `transports`                                                             *
-  *                                                                          *
-  * A array of allowed transport methods which the clients will try to use.  *
-  * On server environments that don't support sticky sessions, the "polling" *
-  * transport should be disabled.                                            *
-  *                                                                          *
-  ***************************************************************************/
-  // transports: ["polling", "websocket"]
-
-};
+/**
+ * WebSocket Server Settings
+ * (sails.config.sockets)
+ *
+ * These settings provide transparent access to the options for Sails'
+ * encapsulated WebSocket server, as well as some additional Sails-specific
+ * configuration layered on top.
+ *
+ * For more information on sockets configuration, including advanced config options, see:
+ * http://sailsjs.org/#!/documentation/reference/sails.config/sails.config.sockets.html
+ */
+
+module.exports.sockets = {
+
+
+  /***************************************************************************
+  *                                                                          *
+  * Node.js (and consequently Sails.js) apps scale horizontally. It's a      *
+  * powerful, efficient approach, but it involves a tiny bit of planning. At *
+  * scale, you'll want to be able to copy your app onto multiple Sails.js    *
+  * servers and throw them behind a load balancer.                           *
+  *                                                                          *
+  * One of the big challenges of scaling an application is that these sorts  *
+  * of clustered deployments cannot share memory, since they are on          *
+  * physically different machines. On top of that, there is no guarantee     *
+  * that a user will "stick" with the same server between requests (whether  *
+  * HTTP or sockets), since the load balancer will route each request to the *
+  * Sails server with the most available resources. However that means that  *
+  * all room/pubsub/socket processing and shared memory has to be offloaded  *
+  * to a shared, remote messaging queue (usually Redis)                      *
+  *                                                                          *
+  * Luckily, Socket.io (and consequently Sails.js) apps support Redis for    *
+  * sockets by default. To enable a remote redis pubsub server, uncomment    *
+  * the config below.                                                        *
+  *                                                                          *
+  * Worth mentioning is that, if `adapter` config is `redis`, but host/port  *
+  * is left unset, Sails will try to connect to redis running on localhost   *
+  * via port 6379                                                            *
+  *                                                                          *
+  ***************************************************************************/
+  // adapter: 'memory',
+
+  //
+  // -OR-
+  //
+
+  // adapter: 'socket.io-redis',
+  // host: '127.0.0.1',
+  // port: 6379,
+  // db: 0,
+  // pass: '<redis auth password>',
+
+
+
+ /***************************************************************************
+  *                                                                          *
+  * Whether to expose a 'get /__getcookie' route with CORS support that sets *
+  * a cookie (this is used by the sails.io.js socket client to get access to *
+  * a 3rd party cookie and to enable sessions).                              *
+  *                                                                          *
+  * Warning: Currently in this scenario, CORS settings apply to interpreted  *
+  * requests sent via a socket.io connection that used this cookie to        *
+  * connect, even for non-browser clients! (e.g. iOS apps, toasters, node.js *
+  * unit tests)                                                              *
+  *                                                                          *
+  ***************************************************************************/
+
+  // grant3rdPartyCookie: true,
+
+
+
+  /***************************************************************************
+  *                                                                          *
+  * `beforeConnect`                                                          *
+  *                                                                          *
+  * This custom beforeConnect function will be run each time BEFORE a new    *
+  * socket is allowed to connect, when the initial socket.io handshake is    *
+  * performed with the server.                                               *
+  *                                                                          *
+  * By default, when a socket tries to connect, Sails allows it, every time. *
+  * (much in the same way any HTTP request is allowed to reach your routes.  *
+  * If no valid cookie was sent, a temporary session will be created for the *
+  * connecting socket.                                                       *
+  *                                                                          *
+  * If the cookie sent as part of the connection request doesn't match any   *
+  * known user session, a new user session is created for it.                *
+  *                                                                          *
+  * In most cases, the user would already have a cookie since they loaded    *
+  * the socket.io client and the initial HTML page you're building.         *
+  *                                                                          *
+  * However, in the case of cross-domain requests, it is possible to receive *
+  * a connection upgrade request WITHOUT A COOKIE (for certain transports)   *
+  * In this case, there is no way to keep track of the requesting user       *
+  * between requests, since there is no identifying information to link      *
+  * him/her with a session. The sails.io.js client solves this by connecting *
+  * to a CORS/jsonp endpoint first to get a 3rd party cookie(fortunately this*
+  * works, even in Safari), then opening the connection.                     *
+  *                                                                          *
+  * You can also pass along a ?cookie query parameter to the upgrade url,    *
+  * which Sails will use in the absence of a proper cookie e.g. (when        *
+  * connecting from the client):                                             *
+  * io.sails.connect('http://localhost:1337?cookie=smokeybear')              *
+  *                                                                          *
+  * Finally note that the user's cookie is NOT (and will never be) accessible*
+  * from client-side javascript. Using HTTP-only cookies is crucial for your *
+  * app's security.                                                          *
+  *                                                                          *
+  ***************************************************************************/
+  // beforeConnect: function(handshake, cb) {
+  //   // `true` allows the connection
+  //   return cb(null, true);
+  //
+  //   // (`false` would reject the connection)
+  // },
+
+
+  /***************************************************************************
+  *                                                                          *
+  * `afterDisconnect`                                                        *
+  *                                                                          *
+  * This custom afterDisconnect function will be run each time a socket      *
+  * disconnects                                                              *
+  *                                                                          *
+  ***************************************************************************/
+  // afterDisconnect: function(session, socket, cb) {
+  //   // By default: do nothing.
+  //   return cb();
+  // },
+
+  /***************************************************************************
+  *                                                                          *
+  * `transports`                                                             *
+  *                                                                          *
+  * A array of allowed transport methods which the clients will try to use.  *
+  * On server environments that don't support sticky sessions, the "polling" *
+  * transport should be disabled.                                            *
+  *                                                                          *
+  ***************************************************************************/
+  // transports: ["polling", "websocket"]
+
+};

package/test/fixture/config/views.js

@@ -1,95 +1,95 @@
-/**
- * View Engine Configuration
- * (sails.config.views)
- *
- * Server-sent views are a classic and effective way to get your app up
- * and running. Views are normally served from controllers.  Below, you can
- * configure your templating language/framework of choice and configure
- * Sails' layout support.
- *
- * For more information on views and layouts, check out:
- * http://sailsjs.org/#!/documentation/concepts/Views
- */
-
-module.exports.views = {
-
-  /****************************************************************************
-  *                                                                           *
-  * View engine (aka template language) to use for your app's *server-side*   *
-  * views                                                                     *
-  *                                                                           *
-  * Sails+Express supports all view engines which implement TJ Holowaychuk's  *
-  * `consolidate.js`, including, but not limited to:                          *
-  *                                                                           *
-  * ejs, jade, handlebars, mustache underscore, hogan, haml, haml-coffee,     *
-  * dust atpl, eco, ect, jazz, jqtpl, JUST, liquor, QEJS, swig, templayed,    *
-  * toffee, walrus, & whiskers                                                *
-  *                                                                           *
-  * For more options, check out the docs:                                     *
-  * https://github.com/balderdashy/sails-wiki/blob/0.9/config.views.md#engine *
-  *                                                                           *
-  ****************************************************************************/
-
-  engine: 'ejs',
-
-
-  /****************************************************************************
-  *                                                                           *
-  * Layouts are simply top-level HTML templates you can use as wrappers for   *
-  * your server-side views. If you're using ejs or jade, you can take         *
-  * advantage of Sails' built-in `layout` support.                            *
-  *                                                                           *
-  * When using a layout, when one of your views is served, it is injected     *
-  * into the `body` partial defined in the layout. This lets you reuse header *
-  * and footer logic between views.                                           *
-  *                                                                           *
-  * NOTE: Layout support is only implemented for the `ejs` view engine!       *
-  *       For most other engines, it is not necessary, since they implement   *
-  *       partials/layouts themselves. In those cases, this config will be    *
-  *       silently ignored.                                                   *
-  *                                                                           *
-  * The `layout` setting may be set to one of the following:                  *
-  *                                                                           *
-  * If `false`, layouts will be disabled. Otherwise, if a string is           *
-  * specified, it will be interpreted as the relative path to your layout     *
-  * file from `views/` folder. (the file extension, ".ejs", should be         *
-  * omitted)                                                                  *
-  *                                                                           *
-  ****************************************************************************/
-
-  /****************************************************************************
-  *                                                                           *
-  * Using Multiple Layouts                                                    *
-  *                                                                           *
-  * If you're using the default `ejs` or `handlebars` Sails supports the use  *
-  * of multiple `layout` files. To take advantage of this, before rendering a *
-  * view, override the `layout` local in your controller by setting           *
-  * `res.locals.layout`. (this is handy if you parts of your app's UI look    *
-  * completely different from each other)                                     *
-  *                                                                           *
-  * e.g. your default might be                                                *
-  * layout: 'layouts/public'                                                  *
-  *                                                                           *
-  * But you might override that in some of your controllers with:             *
-  * layout: 'layouts/internal'                                                *
-  *                                                                           *
-  ****************************************************************************/
-
-  layout: 'layout',
-
-  /****************************************************************************
-  *                                                                           *
-  * Partials are simply top-level snippets you can leverage to reuse template *
-  * for your server-side views. If you're using handlebars, you can take      *
-  * advantage of Sails' built-in `partials` support.                          *
-  *                                                                           *
-  * If `false` or empty partials will be located in the same folder as views. *
-  * Otherwise, if a string is specified, it will be interpreted as the        *
-  * relative path to your partial files from `views/` folder.                 *
-  *                                                                           *
-  ****************************************************************************/
-
-  partials: false
-
-
+/**
+ * View Engine Configuration
+ * (sails.config.views)
+ *
+ * Server-sent views are a classic and effective way to get your app up
+ * and running. Views are normally served from controllers.  Below, you can
+ * configure your templating language/framework of choice and configure
+ * Sails' layout support.
+ *
+ * For more information on views and layouts, check out:
+ * http://sailsjs.org/#!/documentation/concepts/Views
+ */
+
+module.exports.views = {
+
+  /****************************************************************************
+  *                                                                           *
+  * View engine (aka template language) to use for your app's *server-side*   *
+  * views                                                                     *
+  *                                                                           *
+  * Sails+Express supports all view engines which implement TJ Holowaychuk's  *
+  * `consolidate.js`, including, but not limited to:                          *
+  *                                                                           *
+  * ejs, jade, handlebars, mustache underscore, hogan, haml, haml-coffee,     *
+  * dust atpl, eco, ect, jazz, jqtpl, JUST, liquor, QEJS, swig, templayed,    *
+  * toffee, walrus, & whiskers                                                *
+  *                                                                           *
+  * For more options, check out the docs:                                     *
+  * https://github.com/balderdashy/sails-wiki/blob/0.9/config.views.md#engine *
+  *                                                                           *
+  ****************************************************************************/
+
+  engine: 'ejs',
+
+
+  /****************************************************************************
+  *                                                                           *
+  * Layouts are simply top-level HTML templates you can use as wrappers for   *
+  * your server-side views. If you're using ejs or jade, you can take         *
+  * advantage of Sails' built-in `layout` support.                            *
+  *                                                                           *
+  * When using a layout, when one of your views is served, it is injected     *
+  * into the `body` partial defined in the layout. This lets you reuse header *
+  * and footer logic between views.                                           *
+  *                                                                           *
+  * NOTE: Layout support is only implemented for the `ejs` view engine!       *
+  *       For most other engines, it is not necessary, since they implement   *
+  *       partials/layouts themselves. In those cases, this config will be    *
+  *       silently ignored.                                                   *
+  *                                                                           *
+  * The `layout` setting may be set to one of the following:                  *
+  *                                                                           *
+  * If `false`, layouts will be disabled. Otherwise, if a string is           *
+  * specified, it will be interpreted as the relative path to your layout     *
+  * file from `views/` folder. (the file extension, ".ejs", should be         *
+  * omitted)                                                                  *
+  *                                                                           *
+  ****************************************************************************/
+
+  /****************************************************************************
+  *                                                                           *
+  * Using Multiple Layouts                                                    *
+  *                                                                           *
+  * If you're using the default `ejs` or `handlebars` Sails supports the use  *
+  * of multiple `layout` files. To take advantage of this, before rendering a *
+  * view, override the `layout` local in your controller by setting           *
+  * `res.locals.layout`. (this is handy if you parts of your app's UI look    *
+  * completely different from each other)                                     *
+  *                                                                           *
+  * e.g. your default might be                                                *
+  * layout: 'layouts/public'                                                  *
+  *                                                                           *
+  * But you might override that in some of your controllers with:             *
+  * layout: 'layouts/internal'                                                *
+  *                                                                           *
+  ****************************************************************************/
+
+  layout: 'layout',
+
+  /****************************************************************************
+  *                                                                           *
+  * Partials are simply top-level snippets you can leverage to reuse template *
+  * for your server-side views. If you're using handlebars, you can take      *
+  * advantage of Sails' built-in `partials` support.                          *
+  *                                                                           *
+  * If `false` or empty partials will be located in the same folder as views. *
+  * Otherwise, if a string is specified, it will be interpreted as the        *
+  * relative path to your partial files from `views/` folder.                 *
+  *                                                                           *
+  ****************************************************************************/
+
+  partials: false
+
+
 };

package/test/fixture/hacks/waterline.js

@@ -0,0 +1,39 @@
+/**
+ * WRONG SAILS HACK
+ */
+
+console.warn("WRONG SAILS HACK v0.2");
+let PWD = process.cwd()
+const replace = require("replace-in-file");
+
+/**
+ * 1.
+ * Patch for allow unknow types
+ * bash equals: find $PWD/node_modules/waterline-schema/ -type f -print0 | xargs -0 sed -i 's|if (_.indexOf(validProperties, propertyName) < 0) {|if (false) {|g'
+ */
+console.log(PWD + "/../**/sails-hook-orm/lib/validate-model-def.js",);
+const results = replace.sync({
+  files: [
+    //for test system
+    PWD + "/../**/sails-hook-orm/lib/validate-model-def.js", 
+    PWD + "/../**/waterline-schema/schema.js",
+    PWD + "/../**/sails-disk/index.js",
+    PWD + "/../**/query/private/normalize-value-to-set.js", 
+ 
+  ], 
+  from: [
+    "(_.isFunction(val.defaultsTo))",
+    "(_.indexOf(validProperties, propertyName) < 0)",
+    "(_.has(attribute, 'defaultsTo') && _.isNull(attribute.defaultsTo))",
+    "(_.has(primaryKeyAttribute, 'defaultsTo') && !_.isUndefined(primaryKeyAttribute, 'defaultsTo'))",
+    "(attribute.required && _.has(attribute, 'defaultsTo') && !_.isUndefined(attribute, 'defaultsTo'))",
+    "(_.has(attribute, 'defaultsTo'))",
+    "(isProvidingNullForIncompatibleOptionalAttr)",
+    "(primaryKeyAttr.required !== true && (!primaryKeyAttr.autoMigrations || primaryKeyAttr.autoMigrations.autoIncrement !== true))"
+  ],
+  to: "(false)",
+});
+
+console.log(results);
+
+// Stranger things

package/test/fixture/package.json

@@ -1,30 +1,33 @@
-{
-  "name": "test-app",
-  "private": true,
-  "version": "0.0.0",
-  "description": "Sails test application",
-  "keywords": [],
-
-  "dependencies": {
-    "@webresto/core": "^1.0.0",
-    "@webresto/graphql": "file:../..",
-    "include-all": "^1.0.8",
-    "rc": "^1.0.1",
-    "request": "^2.88.2",
-    "sails": "^1.5.0",
-    "sails-hook-orm": "^2.1.1",
-    "sails-hook-stateflow": "^1.0.6",
-    "sails-memory": "^0.10.7"
-  },
-  "scripts": {
-    "debug": "node debug app.js",
-    "start": "node app.js"
-  },
-  "main": "app.js",
-  "repository": {
-    "type": "git",
-    "url": "git://github.com/webresto/app.git"
-  },
-  "author": "webresto",
-  "license": "MIT"
-}
+{
+  "name": "test-app",
+  "private": true,
+  "version": "0.0.0",
+  "description": "Sails test application",
+  "keywords": [],
+  "dependencies": {
+    "@webresto/core": "file:../../node_modules/@webresto/core",
+    "@webresto/graphql": "file:../..",
+    "@webresto/worktime": "file:../../node_modules/@webresto/worktime",
+    "replace-in-file": "^6.3.2",
+    "include-all": "^1.0.8",
+    "rc": "^1.0.1",
+    "request": "^2.88.2",
+    "sails": "^1.5.0",
+    "sails-hook-orm": "^2.1.1",
+    "sails-hook-stateflow": "^1.0.6",
+    "connect-flash": "^0.1.1",
+    "sails-memory": "^0.10.7"
+  },
+  "scripts": {
+    "debug": "node debug app.js",
+    "start": "node app.js",
+    "postinstall": "node ./hacks/waterline.js"
+  },
+  "main": "app.js",
+  "repository": {
+    "type": "git",
+    "url": "git://github.com/webresto/app.git"
+  },
+  "author": "webresto",
+  "license": "MIT"
+}