

Hood: A transactional, database-agnostic ORM for Go - eaigner
https://github.com/eaigner/hood

======
buro9
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?

~~~
meaty
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.

~~~
buro9
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.

~~~
meaty
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.

------
sunfmin
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?

~~~
eaigner
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.

------
lalwat
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)>].

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

------
jspthrowaway2
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...)

~~~
eaigner
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!

~~~
jspthrowaway2
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.

~~~
eaigner
fixed:
[https://github.com/eaigner/hood/commit/7e7742dfd1aff966c6745...](https://github.com/eaigner/hood/commit/7e7742dfd1aff966c6745c4bfa195148171f5aa2)

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

~~~
afandian
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.

~~~
chimeracoder
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.

