
Show HN: Sqlkit – Golang SQL package with nested transactions - kodebrew
https://github.com/colinjfw/sqlkit
======
wilsonfiifi
Another nice Go(lang) package for database access that doesn't get in your way
when you want to drop down to pure SQL is db [0] by upper.io.

    
    
      [0] https://upper.io/db.v3

~~~
ereyes01
For me it doesn't get more seamless than github.com/jmoiron/sqlx

No frills, just a little reflection to tie struct fields <=> SQL params.

------
wrs
>nullable types are converted into their default value in golang

This just seems...wrong. Why would the column be nullable if you don’t
actually care if it’s NULL?

~~~
pushpop
In my experience most of the time a field is nullable it’s by accident. Some
RDBMS and/or SQL “IDEs” default to allowing null too, which doesn’t help
matters. Personally I think NULL shouldn’t be supported unless the developer
categorically sets a “yes, I actually do want this archaic option enabled”
flag in their DB backend.

Edit: getting a lot of heat for this comment from people misunderstanding it.
I’m not saying “null” shouldn’t exist, just that it shouldn’t be the default.
Side point: most of the time people think they need null they don’t.

~~~
andreareina
I agree that NOT NULL should be the default for columns, unfortunately that
ship has sailed.

Assuming that the nullable foreign key problem could be solved, I think that
NULL is valuable enough (and not that rare) that it ought to be the database
owner's choice whether to allow them or not, as opposed to the superuser (not
sure which way you're suggesting).

~~~
pushpop
> _I agree that NOT NULL should be the default for columns, unfortunately that
> ship has sailed._

Not really. Defaults change all the time. I’m not asking for a feature to be
removed after all.

I don’t deny the change in any specific RDBMS would have to be carefully
considered but I’ve worked on a lot harder projects to make transitions in
default behaviours than this would be so it’s certainly doable if the momentum
was there. However I doubt enough people care enough (if this thread is
anything to go by).

> _Assuming that the nullable foreign key problem could be solved_

Offhand I can think of a few ways to solve that but I also think it’s one of
the instances where NULL makes the most sense

> _I think that NULL is valuable enough (and not that rare) that it ought to
> be the database owner 's choice whether to allow them or not, as opposed to
> the superuser (not sure which way you're suggesting)._

I completely agree the DBA should still have the power to enable it. My point
was just that columns shouldn’t default to being nullable during a CREATE.

To be honest, this could just as easily be “fixed” in graphical database
management tools. That would at least enable seasoned DBAs to utilise NULL
while preventing others from some of the pitfalls that nullable fields can
introduce in some languages. However I still stand by my point that it’s not
really a sane default for the way most people architect databases these days
(or even “should” be architecting).

------
dewey
Two small issues and one question:

\- the link to GoDoc is not working yet:
[https://godoc.org/github.com/colinjfw/sqlkit](https://godoc.org/github.com/colinjfw/sqlkit)

\- Typo in the README: Unmarsal instead of Unmarshal

Without going through everything in detail, why would I pick this over the
very popular sqlx?
[https://github.com/jmoiron/sqlx](https://github.com/jmoiron/sqlx)

~~~
kodebrew
Thanks for finding the typos!

Short answer: It's sqlx + a query builder + some extras around transaction
management.

