I quite like ORMs for simple things (the first 80%), but I don't necessarily want the ORM to control schema generation and migration (I very much want integrity to be a database supported feature rather than a feature of the ORM).

As I note the author is also the submitter, a question: Is it a design goal or possibility to use the ORM but to disable schema generation/migration?

Schema management is one of the features I really want to use in an orm as it's the main pain in the ass when it comes to dealing with relational databases.

Oh it's fine for those whose schemas fit into the type that the ORM can generate, I have no issue with the functionality existing at all. For many databases this actually is all that will ever be needed.

But for legacy databases, for the edge cases where the schema is designed for a very specific purpose that doesn't neatly fit what the ORM would generate, and especially when external applications may also call the database... I like to know that the database is exactly what I expect it to be.

I have a 2000 table, 45000 sproc legacy database on my hands. 20 mins to deploy the schema. Its what we expect but the maintenance cost is extreme, its not testable.

That's where the ORM comes in for legacy stuff. We're moving the schema slowly into the ORM.

schema creation is completely optional, you don't have to use it.

I actually want to see this:

    hd.Where("name = ?", name).Where("category = ?", category)

So that you can do conditional where easily, for example:

    hd = hd.Where("name = ?", name)
    if category != "" {
        hd = hd.Where("category = ?", category)
    }

But It doesn't seem to support this?

As for now, you have to specify the complete where clause

    hd.Where("name = ? AND category = ?", name, category)

but it should be quite trivial to add the chaining you pointed out.

Quick fix: https://github.com/eaigner/hood/commit/85948f72646e6703af09e...

I would not use "... for Go!" in the description due to the other programming language named "Go!" [http://en.wikipedia.org/wiki/Go!_(programming_language)].

Making an RDBMS feel more like labix.org/mgo.. I like it!

I'll open an issue in Github about this, but you shouldn't own the entire struct tag, and there is a convention for this. If I want to serialize the same object to JSON, I should be able to (I can with the way it works right now, but I cannot customize the JSON encoding at all).

Follow convention:

    type Foo struct {
        Thing string `json:"thinger,omitempty" hood:"pk"`
    }

Or, even, get bold and claim sql:

    type Foo struct {
        Thing string `json:"thinger,omitempty" sql:"size(128)"`
    }

You can then use stuff built in to reflect to get the information for you, rather than parsing yourself:

http://golang.org/pkg/reflect/#StructTag

That aside, great work! I've been waiting for something like this.

(Edit: Someone already beat me to it: https://github.com/eaigner/hood/issues/1 -- Hacker Newsers think alike, I guess...)

That's a valid issue, definitely want to conform with Go standards and don't break anything. Like the "sql:" proposal very much, will change it to that!

I thought about it after commenting and was trying to think of a loose vocabulary you could introduce for "sql" to be interoperable among as-yet unwritten libraries, as jedsmith says on Github, and that's a pretty tough nut to crack. Letting it evolve over time is probably the right choice, so will be interesting to see how your choices impact the SQL landscape down the road.

fixed: https://github.com/eaigner/hood/commit/7e7742dfd1aff966c6745...

Matching the json-tag style will probably be the best bet (using commas, e.g. `sql:"size(128),default('abc')"`)

An 'ORM' for a downright Anti-OO language? Funny.

Do you know anything about Go? It's very OO indeed. Certain polymorphic bits aren't there, and no C++ type inheritance. But otherwise very OO.

I'd say it's much more in line with Alan Kay's definition[1] of OO than most other languages.

It's statically typed, so it can check at compile-time that the "messages" being passed are valid, but the dispatch of the messages (ie, methods) is determined by the struct itself, which has the same effect as "extreme late binding" (Kay's words) - the only difference is that Go's type system permits much of this to happen at compile-time anyway.

[1] Which, incidentally, explicitly mentions inheritance as not being a defining point of OO programming.