If you don't find your question here, open an issue or contact us directly.
-
Implementing Obelisk as your data store provides search capability "out of the box". Obelisk's scripting language is a dialect of SQL, the most powerful database language there is. Dynamically generate urQL queries or use the Obelisk API directly. (But protect yourself from SQL injection attacks, just like you must do in other programming environments.) Search your data and/or mixed data sets with the full power of first order predicate calculus.
-
Mash-up your app's data with data from other apps and personal data. Obelisk allows for cross-database queries and someday even cross-server (cross-ship) queries.
-
Reliance on a data store that provides for good data hygiene. Obelisk provides not only for storing data using the relational model, but unlike other SQL databases, Obelisk data sets are always proper sets. Full relational integrity is on the roadmap.
-
Never lose your data. Obelisk's unique time traveling capability means if you delete or overwrite the wrong data you can always recover.
-
Built in auditing of content and schema changes via Obelisk time traveling.
Obelisk comes with a sample database and instructions on loading it in the Users Guide.
It also integrates with the popular %hawk app which provides an ad hoc scripting environment much like popular "SQL Studio" apps. Get the latest Obelisk UI.
Read the Preliminaries document, especially the last section on Time to understand Obelisk's unique time traveling capabilities.
The second beta release of Obelisk will include user-defined views.
Obelisk's unique time-traveling capability provides for all SELECT queries being implicitly idempotent. This allows us to cache view results, meaning that whenever underlying content changes there is a one-time performance hit while the system performs a raw SELECT query and caches the results. We believe this will result in sub-half-second queries on views.
In principle there is no reason we cannot cache every SELECT query's results and look-up whether a query has been cached.
That being said, we are always working on improving Obelisk's query plan execution performance.
We are talking to the Urbit Foundation about integrating the Obelisk RDBMS directly into Urbit by making Obelisk a vane. Reach out to us about this and let the foundation know you want a time-traveling RDBMS vane.
Take a look at the roadmap. Chances are the functionality you require is there. Open an issue or contact us directly and we will prioritize it.
Reach out to us. We can provide assistance in normalizing an RDBMS data model for you. The roadmap includes permitting columns of non-atomic nouns. If this would be helpful for you we can prioritize.
Currently Obelisk can only be accessed from the host ship. The roadmap includes a fine-grained security model for foreign ship access. If this would be helpful for you we can prioritize. You can still expose your Obelisk data through a publicly available app, c.f. the question about SQL injection.
You may want to allow injection of some SQL commands in your app. The general solution is to submit your script to the Obelisk parser which returns a list of Obelisk API commands. Filter on the commands you want to allow and submit those for execution, or construct API commands directly.
RTFM. Obelisk has comprehensive reference documents and Users Guide. If any SQL RDBMS can do it, Obelisk can or it is on the roadmap.
And Obelisk can do much more, like built it data recovery and change auditing. And because data sets are always proper sets data hygiene is better than any other SQL database.