Getting the database connection data from parameters

[Simon Brooke]

This ought to be simple, but I haven't (yet) worked out how to do it, and I'm sure someone else must have solved it.

I'm writing a little tool which does analysis of history databases written by our systems in the field; the databases are (typically, not always) held in Microsoft SQL Server instances on different machines. In future there may also be Postgres instances. Currently I'm declaring the database as follows:

(db/defdb fpphistory {:subprotocol "jtds:sqlserver"

               :subname "//127.0.0.1//history"

               :user "sgs-historian"

               :password "xxxxxxxxx"})

which works fine in development, but in production the tool will rarely or never run on the machine the DBMS sits on, and although the name of the database is currently always 'history', this also won't necessarily always be true in future.

I've got a -main function in which I already parse command line arguments. I'd like to pass in the sub-protocol, the host address, the database name, the username and the password as command line arguments. Any suggestions as to how I do this?

Any help gratefully received!

[Dennis Roberts]

Since you're using `defdb`, the code is evaluated when the namespace is loaded. We've handled this by calling `create-db` and `default-connection` directly in at least one of our services:

https://github.com/cyverse/DE/blob/master/services/apps/src/apps/kormadb.clj

Another option is to call `defdb` inside a function:

https://github.com/cyverse/DE/blob/master/tools/facepalm/src/facepalm/core.clj#L185-L201

You can also skip defining the symbol, which will avoid linter warnings:

https://github.com/cyverse/DE/blob/master/services/saved-searches/src/saved_searches/config.clj#L20-L38

Dennis

--
You received this message because you are subscribed to the Google Groups "Korma" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sqlkorma+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dennis Roberts]

I should have said, "since you're using defdb outside of a function..."

[Simon Brooke]

Thanks! That looks most helpful. One way or the other I should be able to get what I need to work.

[Simon Brooke]

For anyone who's following this, the key to getting it to work is NOT having a 'database' specification in your defentity declarations. So instead of:

(ns opsdata.db

  "Database interface definition, and functions which interact with the

  database directly."

  (:require [korma.db :as db]

            [korma.core :as kc]

            [taoensso.timbre :as logger]

            [clj-time.coerce :as tc]

            [opsdata.time-series :as otc]))

;; the HISTORY table.

(kc/defentity history

                 (kc/pk :idhistory)

                 (kc/table :dbo.history)

                 (kc/database history-db)

                 (kc/belongs-to currentvalues {:fk :nameid})

                 (kc/entity-fields :idhistory :system :timestamp :nameid :stringvalue :value))

you need

;; the HISTORY table.

(kc/defentity history

                 (kc/pk :idhistory)

                 (kc/table :dbo.history)

                 (kc/belongs-to currentvalues {:fk :nameid})

                 (kc/entity-fields :idhistory :system :timestamp :nameid :stringvalue :value))

Once you've made that change, Korma will use the 'current' (I think = latest defined) database to connect to the table, and everything is rosy.

D'oh!