I am working with a sails application that uses Sequelize as the ORM tool. Initial integration between the app and Sequelize was established via the sails-hook-sequelize plugin which can be found here. This approach has worked great so far, no problem defining and using models.
However, I hit a road block when I wanted to define a View as a Sequelize object. Sequelize doesn't (yet) have an easy way to do this. The work around I found was to execute a raw query and populate a table with the result.
Now I come to the second road block and the actual question itself. How do I simply execute a sequelize.query inside of my sails application? In stand alone node apps using sequelize I don't have a problem. However, this sails application has gotten away from me to the point where I'm not sure what object to actually call .query from! What I'm looking for is something simple like
Sequelize.query("SELECT * FROM `Document.MyView`", { type: Sequelize.QueryTypes.SELECT})
Sadly the above gives me sequelize.query is not a function
I have a connections.coffee file where the database connection is defined. It is named 'Core', however when I try Core.query I get Core is undefined
Seems like I am missing something simple and fundamental from stacking too many things on top of the other.
Alright my problems arose from the sails-hook-sequelize plugin. Luckily my answer came from that plugin as well!
"sequelize" is a global in this plugin. So don't add a sequelize = require 'sequelize'.
simply call the raw query with sequelize.query as expected (case sensitive).
Then your raw query should work! Thanks from past me.
Related
Background:
I'm building an SPA (Single Page Application) PWA (Progressive Web App) using Vue.js. I've a remote PostgreSQL database, serving the tables over HTTP with PostgREST. I've a working Workbox Service Worker and IndexedDB, which hold a local copy of the database tables. I've also registered some routes in my service-worker.js; everything is fine this far....
I'm letting Workbox cache GET calls that return tables from the REST service. For example:
https://www.example.com/api/customers will return a json object of the customers.
workbox.routing.registerRoute('https://www.example.com/api/customers', workbox.strategies.staleWhileRevalidate())
At this point, I need Workbox to do the stale-while-revalidate pattern, but to:
Not use a cache, but instead return the local version of this table, which I have stored in IndexedDB. (the cache part)
Make the REST call, and update the local version, if it has changed. (the network part)
I'm almost certain that there is no configurable option for this in this workbox strategy. So I would write the code for this, which should be fairly simple. The retrieval of the cache is simply to return the contents of the requested table from IndexedDB. For the update part, I'm thinking to add a data revision number to compare against. And thus decide if I need to update the local database.
Anyway, we're now zooming in on the actual question:
Question:
Is this actually a good way to use Workbox Routes/Caching, or am I now misusing the technology because I use IndexedDB as the cache?
and
How can I make my own version of the StaleWhileRevalidate strategy? I would be happy to understand how to simply make a copy of the existing Workbox version and be able to import it and use it in my Vue.js Service Worker. From there I can make my own necessary code changes.
To make this question a bit easier to answer, these are the underlying subquestions:
First of all, the StaleWhileRevalidate.ts (see link below) is a .ts (TypeScript?) file. Can (should) I simply import this as a module? I propably can. but then I get errors:
When I to import my custom CustomStaleWhileRevalidate.ts in my main.js, I get errors on all of the current import statements because (of course) the workbox-core/_private/ directory doesn't exist.
How to approach this?
This is the current implementation on Github:
https://github.com/GoogleChrome/workbox/blob/master/packages/workbox-strategies/src/StaleWhileRevalidate.ts
I don't think using the built-in StaleWhileRevalidate strategy is the right approach here. It might be possible to do what you're describing using StaleWhileRevalidate along with a number of custom plugin callbacks to override the default behavior... but honestly, you'd end up changing so much via plugins that starting from scratch would make more sense.
What I'd recommend that you do instead is to write a custom handlerCallback function that implements exactly the logic you want, and returns a Response.
// Your full logic goes here.
async function myCustomHandler({event, request}) {
event.waitUntil((() => {
const idbStuff = ...;
const networkResponse = await fetch(...);
// Some IDB operation go here.
return finalResponse;
})());
}
workbox.routing.registerRoute(
'https://www.example.com/api/customers',
myCustomHandler
);
You could do this without Workbox as well, but if you're using Workbox to handle some of your unrelated caching needs, it's probably easiest to also register this logic via a Workbox route.
When trying to use Waterline standalone mode, I could not find the correct method to perform native queries. With Sails.JS the sendNativeQuery method is used which I could not find in the instances of the models. Does anyone know how I can perform these queries?
Thank you!
I have the same problem, i think it sail who set getDatastore() and sendNativeQuery() function on model and datastore.
Surely on this file: https://github.com/balderdashy/sails-hook-orm/blob/master/lib/build-registered-datastore-instance.js
and the function is defined here: https://github.com/balderdashy/sails-hook-orm/blob/master/lib/build-registered-datastore-instance.js
Im going to implement this in my code but if someone have a better idea or have already doing this i appreciate help :)
Sails enables you to access what called datastore.manager
Depending on the adapter, this might represent a connection pool, a single connection, or even just a reference to a pre-configured client library instance.
If you are using MongoDB for example, you can have a raw Mongo collection instance.
see here.
Pretty simple you'd think given the popularity of both, but I am encountering a few hurdles.
I am using scaphold.io to be able to quickly show off a working UI. That is, if Vue can interact with Scaphold.
I have investigated two resources:
https://github.com/kristianmandrup/vue2-apollo-scaphold
Which seems to be a Scaphold production. Tried it. Many, many vague bugs.
Then there is also:
https://github.com/Akryum/vue-apollo
But this is too much. I don't need a server, the server is on Scaphold.
I also tried building the whole thing up by using the tutorial on howtographql, but this one is also outdated.
Ideally I want to instantiate an as up to date Vue 2 app using (I guess) the npm vue-cli, then install only the required apollo (or whatever, but I guess apollo) add-ons that I need. The minimum.
Shouldn't be too hard, I'll figure it out eventually, but some help is more than welcome.
You can consume a graphql api using your favorite regular request module (ajax, fetch, axios). Take the scalphold docs for example, but in the callback do this.vueUserData = body.data.getUser;
instead of
console.log(JSON.stringify(body, null, 2));
(edited to add one gotcha I remembered: if you encounter a problem where the callback doesn't know that this is supposed to be the component, you can do var self = this before the request function, then reference self.vueUserData instead.)
Is it possible to use for example Sequelize, Bookshelf or Waterline inside meteor ?
I want to use Meteor as a classic backend, so just using Restivus to build my Rest API and need to communicate with some external DBs. It doesn't need to be reactive or to be ''live query''.
In principle you could, but since Meteor uses Fibers you would have to wrap calls. I had to migrate some sqlite3 data in the past and using a Fiber to wrap db calls worked. Was something like this
var Fiber = Npm.require('fibers');
db.method('query', function(){
Fiber(function(){
// more queries
}).run();
});
Or around the same idea, I would have to look at the code to be sure but that was around those lines.
I'm trying to follow the basic cometd example here: http://dojotoolkit.org/reference-guide/1.7/dojox/cometd.html
It's using the old module loader so I tried the equivalent as follows:
require(["dojo/ready","dojo/io/script","dojox/cometd","dojox/cometd/callbackPollTransport"], function(ready, dontcare, cometd) {
ready(function(){
cometd.init('http://localhost:8080/MyCometD/cometd');
comted.subscribe("/test", function(msg){
console.debug(msg);
});
});
});
This doesn't work and I think it has to do with loading modules - there is some sort of silent error as the code within the ready function does not execute at all. What I found is that when the "dojox/cometd" require statement is present, the code within the ready function does not execute.
Running example: http://jsfiddle.net/Q9W8f/2/
Example with dojox/comted removed: http://jsfiddle.net/mMs2h/4/
I haven't worked with the new module loader that much so I bet I just have some simple misconception.
Help!
It seems like youre correct and that there is a 'wait-loop' for a module requirement that never gets loaded. This may be any of the requirements inside dojox.cometd and you'd need to rewrite the codebase for a fix.
I have had similar issue with the RollingListPane, also in dojox repository - and the developers are saying 'we are 100% AMD compliant with 1.7' however the X in dojox is short for experimental. The developement of dojox modules is not done by the core djtk team and there are still glitches..
Try for starters to avoid using CDN which has performed a >>built macro on every single module. This tends to fail at times whilst using AMD. Instead download the tarball and use a local copy - Not compressed (dojo-release-1.7.2-src)
You can find the hello world example in cometD and ExtJs at following link:
http://jksnu.blogspot.in/2013/08/network-reliability-by-cometd-hellow_16.html