lib-onyx is a utilities library to make working with Onyx's extensibility features easier out of the box.

On Clojars:

[org.onyxplatform/lib-onyx "0.14.1.0"]

• Clojure API
• HTTP API

View every update to the Onyx Log as it happens. Just supply your peer configuration:

(require '[lib-onyx.log-subscriber :as s])

(def subscriber (s/start-log-subscriber your-peer-config))

(println (:replica @(:state subscriber))
(println (:as-of-entry @(:state subscriber)))
(println (:as-of-timestamp @(:state subscriber)))

(s/stop-log-subscriber subscriber)

See the API docs listed above for more information.

Given a log subscriber, use convenience functions to query the replica state. All functions take a dereferenced replica so that they can operate on a stable, immutable value:

(require '[lib-onyx.replica-query :as rq])
(require '[lib-onyx.log-subscriber :as s])

(def subscriber (s/start-log-subscriber your-peer-config))

(def replica (rq/deref-replica subscriber)

(println (rq/jobs replica))

(println (rq/peers replica))

(s/stop-log-subscriber subscriber)

See the API docs listed above for more information.

lib-onyx exposes an HTTP server to service replica and cluster queries across languages.

(require '[lib-onyx.lib-onyx.replica-query-server :as rqs])

(def server-port 3000)

(def server (rqs/start-replica-query-server peer-config server-port)

Then query it:

$ http --json https://localhost:3000/replica/peers

HTTP/1.1 200 OK
Content-Length: 197
Content-Type: application/json
Date: Tue, 23 Feb 2016 03:35:08 GMT
Server: Jetty(9.2.10.v20150310)

{
    "as-of-entry": 12,
    "as-of-timestamp": 1456108757818,
    "result": [
        "e52df81d-38c9-44e6-9e3d-177d3e83292b",
        "fd4725f9-3429-49eb-840d-6c3e29cecc41",
        "fc933dda-7260-4547-93fc-241a02ca599a"
    ],
    "status": "success"
}

See the HTTP docs listed at the top of this page for all the endpoints.

And bring it back it down with:

(rqs/stop-replica-query-server server)

lib-onyx add's support for using Joplin db migrations as a prerequisite for job start. This will ensure that your target database is in the correct state before Onyx starts reading/writing to it. You must include your specific database dependency and the relevant config. These are listed on the https://github.com/juxt/joplin README.md.

From there, provide a joplin config. This is an example if you're using Aero. If not, the #path tags are just get-in ks syntax for config file traversal.

 :joplin-config
 {:databases {:sql {:type :sql
                    :url "jdbc:mysql:https://192.168.99.100:3306/onyx?user=admin&password=mypass"
                    :migrations-table "ragtime_migrations"}}
  :migrators {:sql-migrator "resources/migrators/sql"}
  :seeds {:sql-seed "my.seed.namespace/run"
  :environments {:dev [{:db #path       [:joplin-config :databases :sql]
                        :migrator #path [:joplin-config :migrators :sql-migrator]
                        :seed #path     [:joplin-config :seeds :sql-seed}]}}

Then, either use the lib-onyx.migrations.sql/joplin lifecycle with the :joplin/config and :joplin/environment keys set in either your catalog or lifecycle map, or use the provided task-bundle middleware with-joplin-migrations to handle the lifecycle and config instrumentation for you.

:joplin/config corresponds to the above config map. Really all you need is the :environments key specified and :joplin/environment will simply ensure up to date migrations for all the environment maps inside the specified environment's vector. In the above case, the {:joplin/environment :dev} would be your only choice.

Copyright © 2016 Distributed Masonry

Distributed under the Eclipse Public License either version 1.0 or (at your option) any later version.