Browserify WIP

[grncdr]

This s not ready for merge, but meant to track progress on some ideas I have.

The motivation is to allow client-side javascript to use the gesundheit API to simplify interactive query building.

The architecture I have in mind is to make gesundheit browserify-able and support marshalling/unmarshalling queries from JSON objects. Then a client-side application can build any possible gesundheit query, turn it into JSON and send it over the wire to the server. The server can then unmarshal it into a Query object, execute it, and send back the results. This much already works, but there are some outstanding issues:

• Security. The server will need to restrict and/or validate the data to be unmarshalled into a query. Because unmarshalling involves a recursive walk over a (parsed) JSON object, it should be possible to plug in a validation visitor that restricts what node types can be unmarshalled (as well as anything else about those nodes, e.g. restrict the tables and columns a particular user has access to).
• Client-side engine. It would be cool if the client-side JavaScript could actually call .execute on a query object, and this would automatically send a request in a predefined format to a user-configurable URL.

/cc @jamalsoueidan

[jamalsoueidan]

I love it :D

Thank you very much,

I faced some problems:

When compiling:

keywords = require('./sql_keywords')
Error: module "./sql_keywords" not found from "/NodeJS/browserify/lib/dialects.js"
There is two files sql_keywords.[json, txt]

I think the solution is to rename sql_keywords.json to sql_keywords.coffee

When running in console:

#gesundheit.select('jobs', ['name', 'id']).compile()
["SELECT jobs.name, jobs.id FROM jobs",
Array[0]
]

#json = gesundheit.select('jobs', ['name', 'id']).toJSON()
Object {_type: "SelectQuery", q: Object}

#object = gesundheit.fromJSON(json)
Error: Can't inflate: {"_type":"SelectQuery","q":{"_type":"Select","projections":{"_type":"SelectColumnSet","glue":", ","nodes":[{"_type":"Column","glue":".","nodes":[{"_type":"Relation","value":"jobs"},{"_type":"Field","value":"name"}]},{"_type":"Column","glue":".","nodes":[{"_type":"Relation","value":"jobs"},{"_type":"Field","value":"id"}]}]},"relations":{"_type":"RelationSet","glue":" ","nodes":[{"_type":"Relation","value":"jobs"}]}}}

I changed:
if (!object._type) to if (object._type)

Then it returnes:
Object {q: Object}
q: Object
projections: Object
relations: Object
proto:

But I cannot use any of the gesundheit methods..

I'm doing something wrong?

[jamalsoueidan]

Well, the security must have some kind of schema, so the client is only allowed to do some kind of actions on the different tables.

'table': {allow: {'select': ['field', 'fields']}} etc.

www.meteor.com have some kind of query-manager in the browser, but I don't know how they handle security.

What do you think?

But again security and client-side engine must be handled by the developer, or else we move to new project.

[grncdr]

gesundheit.fromJSON(json)
...
I'm doing something wrong?

Sorry, gesundheit.fromJSON is actually the wrong method. It only handles unmarshalling of AST nodes, to unmarshall a query, use gesundheit.queries.inflate(jsonData). This function name will change in the future, but that will at least get you started.

[grncdr]

'table': {allow: {'select': ['field', 'fields']}}

I think that would be configuration for the validator object supplied to the fromJSON/inflate function. For the first implementation I only want to implement pluggable validators in the unmarshalling process.

I would then much prefer to merge an implementation of a validator object that somebody has used in a real application rather than write one myself. I think that whitelisting (query type, table, column) would cover a lot of ground. Another extremely common use case would be providing callbacks that only allow access to a certain tables/column if the query has a given restriction (e.g. user can only access their own data), or even automatically add such restrictions.

[grncdr]

BTW I fixed the sql_keywords file so that it is present again... though I'm thinking your solution might be better, as there's no reason that I can see for the client code to worry about quoting keywords.

[jamalsoueidan]

I tried to submit a commit but I got access denied.

[grncdr]

yes you must fork and send a pull request. Check out this help topic

[jamalsoueidan]

I will look at the code :)

Thank you...