Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

[Script] JSQL -- SQL-like access to state

1464023508
Lithl
Pro
Sheet Author
API Scripter
Note: this script is very much &nbsp;not complete. This is simply the first version complete enough to release to the public. Code:&nbsp; <a href="https://github.com/Lithl/roll20-api-scripts/tree/jsql/JSQL" rel="nofollow">https://github.com/Lithl/roll20-api-scripts/tree/jsql/JSQL</a> Version: &nbsp;0.6 JSQL gives you access to the state &nbsp;object in a fashion similar to Structured Query Language accessing a database. JSQL is based on the capabilities -- but is not a direct port -- of SQLite. JSQL does not offer any increases in speed for accessing large amounts of data like an actual database. That said, you should not be storing enough information in state &nbsp;to need that kind of speedup in the first place. JSQL does not have indexes, and it doesn't enforce unique or foreign keys on tables at this time. What JSQL does do is a bit too much to go over in a single forum post. As such, I've created a wiki to document everything. Assuming the script eventually reaches a point where I'm willing to submit it to the Roll20 api scripts repo, I'll port this documentation over to the Roll20 wiki, but until then you can view the JSQL documentation here:&nbsp; <a href="https://github.com/Lithl/roll20-api-scripts/wiki/JSQL" rel="nofollow">https://github.com/Lithl/roll20-api-scripts/wiki/JSQL</a> Of particular note on the documentation wiki is the&nbsp; known bugs/missing features page. To summarize: Expression objects are only reliable in where clauses. There are other places they are meant to be usable, but most of them don't currently function. where(...String) (parsing one or more strings to build Expression objects) is not currently implemented. Make sure you pass already-constructed Expressions to a where clause. Subqueries in insert and select queries are not implemented Select queries are only partially implemented. Currently, specifying the fields to select is ignored, as are groupBy and joins (including implicit inner joins by selecting from multiple tables). The triggerParamsAsObjects option for trigger functions is currently being trated as false &nbsp;regardless of its actual value.
1464028960
Ada L.
Pro
Marketplace Creator
Sheet Author
API Scripter
Sounds great for scripts that have to load/manipulate information from a large compendium of stuff like spells and monsters. :)