How to connect to the database

[J. Pablo Fernández]

Hello,

I really like where Lobos is going, this is the library I was going to build myself if it didn't exist.

At the moment, I'm trying to figure out all the details, like where you put the connection so that it's always loaded, but once and only once?

Thanks.

[Nicolas Buduroi]

On Tuesday, August 16, 2011 11:18:01 AM UTC-4, J. Pablo Fernández wrote:

I really like where Lobos is going, this is the library I was going to build myself if it didn't exist.

Thanks!
 

At the moment, I'm trying to figure out all the details, like where you put the connection so that it's always loaded, but once and only once?

For now I've decided to put the connection definition (and any other generic configuration stuff) in the `src/lobos/config.clj` file in my local projects. That namespace is use by the migration generator when creating the file containing the lobos.migrations namespace. This can be overrided by rebinding the `lobos.migration/*config-namespace*` var. I'm still not sure this is the best way to do that, so it may change before the 1.0 release if someone suggest me a better solution or I find one myself.

[J. Pablo Fernández]

Hello Nicolas,

Thanks for the quick reply.

About the naming, I can't say for sure but I think it'd be better if it's not in the lobos package. If a new person arrives at a project, "lobos" doesn't mean database immediately (maybe it will in the future). I like in Rails how directories are named after what they are and not the different libraries.

By migration generator you mean lobos.core/dump?

I wrote this simple migration:

(ns mgr.lobos.migrations

  (:refer-clojure :exclude [alter defonce drop bigint boolean char double float time])

  (:require lobos.connectivity)

  (:use [lobos [migration :only [defmigration]] core schema]

        lobos.config))

(defmigration create-admins

  (up [] (create (table :users (integer :id :primary-key))))

  (down [] (drop (table :users))))

and when I try to run it I get an error:

user=> (lobos.core/run)

java.util.IllegalFormatConversionException: d != java.lang.String (NO_SOURCE_FILE:0)

I think that's because I'm not passing the db argument to create and drop, is it?

[Nicolas Buduroi]

On Tuesday, August 16, 2011 12:02:56 PM UTC-4, J. Pablo Fernández wrote:

About the naming, I can't say for sure but I think it'd be better if it's not in the lobos package. If a new person arrives at a project, "lobos" doesn't mean database immediately (maybe it will in the future). I like in Rails how directories are named after what they are and not the different libraries.

Yeah, I was thorn about this decision, I'll think about it again.

By migration generator you mean lobos.core/dump?

Yes

 

I wrote this simple migration:

(ns mgr.lobos.migrations

  (:refer-clojure :exclude [alter defonce drop bigint boolean char double float time])

  (:require lobos.connectivity)

  (:use [lobos [migration :only [defmigration]] core schema]

        lobos.config))

(defmigration create-admins

  (up [] (create (table :users (integer :id :primary-key))))

  (down [] (drop (table :users))))

and when I try to run it I get an error:

user=> (lobos.core/run)

java.util.IllegalFormatConversionException: d != java.lang.String (NO_SOURCE_FILE:0)

I think that's because I'm not passing the db argument to create and drop, is it?

It most probably is, although I don't recognize that error message. I could look more into this later (or tomorrow) if you can't fix this bug.
 

[J. Pablo Fernández]

Maybe once I see the whole picture I'll be able to provide more feedback. For now I have this very simple file that triggers the error I posted before:

(ns lobos.migrations

  (:refer-clojure :exclude [alter defonce drop bigint boolean char double float time])

  (:use (lobos [migration :only [defmigration]] core schema)

        lobos.config)

  (:require lobos.connectivity

            lobos.core))

(def db

  {:classname "org.postgresql.Driver"

   :subprotocol "postgresql"

   :subname "//localhost:5432/mgr"})

(lobos.connectivity/open-global db)

(defmigration create-admins

  (up [] (println "up"))

  (down [] (println "down")))

(lobos.core/run)

The error is:

java.util.IllegalFormatConversionException: d != java.lang.String (migrations.clj:1)

In #clojure they say it's probably a macro failing. I couldn't figure it out yet but as I'll be away for a couple of days I wanted to post what I got so far.

Thanks.

[J. Pablo Fernández]

Some more information I got. The problem seems to be here:

user=> (lobos.migration/create-migrations-table {:classname "org.postgresql.Driver", :subprotocol "postgresql", :subname "//localhost:5432/mgr"} nil)

java.util.IllegalFormatConversionException: d != java.lang.String (NO_SOURCE_FILE:0)

and I wonder if the second argument should be nil at all, but that's what optional-cnx-and-sname is returning:

user=> (lobos.internal/optional-cnx-and-sname [])

[{:classname "org.postgresql.Driver", :subprotocol "postgresql", :subname "//localhost:5432/mgr"} nil nil]

[J. Pablo Fernández]

Continuing tracking down the issue, basically every function that should return an schema name, or sname, returns nil and the failure happens in lobos.analyzer/analyze-schema (https://github.com/budu/lobos/blob/master/src/lobos/analyzer.clj#L178). Like in all other cases, sname is nil, so it ends up calling (analyze Schema nil). Not sure if that should handle nil or nil should never get there.

[Nicolas Buduroi]

I've figured it out, this was a subtle one. It was because the migration commands like run or rollback need to look at the lobos_migrations table to know what to do. When there's no schema given, Lobos try to look for the default schema using the built-in analyzer, but in the case of Postgres (like most other RDBMS) there's no generic way to figure it out, so it need to use the specific backend in which I hardcoded the default schema name. The main issue was that the postgres backend wasn't loaded automatically at this point, I've fixed that and pushed a new SNAPSHOT release to Clojar.

Thanks for the exhaustive error report!

2011/8/16 J. Pablo Fernández <pup...@pupeno.com>