Show HN: Sqlkit – Golang SQL package with nested transactions

https://github.com/colinjfw/sqlkit

by kodebrew • 7 years ago

65 46 7 years ago

github.com

wrs3• 7 years ago

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?

pxue2• 7 years ago

Follow up questions:

if I read out a nullable text field and write the same struct back into the database is it going to insert an empty string into that column?

Also related, how would auto incr pk work?

kodebrew4• 7 years ago

Yes I think it would insert an empty string. I think all the tests are using uuid's as primary keys, this is a good point -- thanks for raising.

pushpop15• 7 years ago

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.

camdenlock• 7 years ago

“Unset” is an extremely valuable state to be able to check. It’s why we have null/nil in well-designed languages. The zero value of a golang int is not the same as indicating a lack of presence. There are plenty of scenarios where “unset” is a necessary state vs the zero value.

trinitry3• 7 years ago

Only if your developers are inexperienced.

marcc2• 7 years ago

Nullable is being set by accident? Nullable values are an “archaic” option?

Nullable is different than empty. Consider a contrived example where I’ve extended a user table to include a new column “fullName”. By making this a nullable column, I can determine that a user has not set this value. But maybe the user sets it to an empty string. The API might want to know this and handle it differently — prompting for a value if it’s null, but ignoring “” as “this is what the user wanted to set”.

Without nullable values, I would have to create bit values in a lot of tables indicating if the value was ever set.

Another example is time stamps. Databases have timestamps for createdAt and updatedAt often. There are people who set updatedAt when they set createdAt, but there are people who don’t. I’m in the later camp. If an object was created but never updated, I want to be able to know that. How would I do this if the updatedAt column is not nullable? I’d either have to set a bit field that it has been updated, which feels suboptimal, or I could set it to something like “time.Empty{}”, which is a magic number tied to the programming language? There are plenty of other solutions here, sure, but what’s wrong with nullable fields?

zzzeek2• 7 years ago

Do you think SQL should have outer joins? Then you need NULL.

wrs3• 7 years ago

Yeah, the world would probably be a better place if the default in a column definition was NOT NULL rather than NULL.

That's not really relevant to this discussion, though -- once you do have a nullable column in your schema, it doesn't make sense in the Go layer to pretend you don't.

andreareina• 7 years ago

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

kodebrew4• 7 years ago

Maybe this is true? I may not have thought through the entire feature that carefully.

The initial thought behind it: Go programmers generally use values for scalars instead of pointers. Can we make an sql mapper that reflects that general practice?

Maybe the answer is no.

vbezhenar• 7 years ago

Java JDBC use similar approach for primitive types and has method wasNull which returns true if the last retrieved value was actually null. I hate that approach, honestly, but that's from Java perspective, may be it's more natural for Go developers.

wrs3• 7 years ago

There's an inherent semantic mismatch here. SQL scalars have a dimension (NULL) that Go scalars don't have, so Go scalars just don't have enough information to represent SQL values. You have to put that dimension somewhere. Rather than using Go's separate dimension of nil-ness of pointers, you could put it in a separate boolean return value, or wrap it in a struct (see C#'s Nullable<T>), or make it queryable with a separate method (like IsNull(index)). Whatever it is, it also has to be two-way, so you can write NULLs as well as read them.

nerdponx• 7 years ago

For any practical usage, this is a fundamentally broken implementation.

I spend something like 10% of my working hours un-fucking data that was poisoned by lazy, inconsistent, and/or incorrect handling of missing data.

This is what makes Excel such a dumpster fire for handling data. It is absolutely the wrong decision to make any new piece of software that handles missing data like this.

Rapzid• 7 years ago

Go's defaults for types are great in a lot of go specific ways, but anyone who has dealt with needing to use pointers all over the place in DTOs knows how disgusting it can get.

kodebrew4• 7 years ago

Agreed.

wilsonfiifi• 7 years ago

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• 7 years ago

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.

dewey• 7 years ago

Two small issues and one question:

- the link to GoDoc is not working yet: 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

kodebrew4• 7 years ago

Thanks for finding the typos!

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

Show HN: Sqlkit – Golang SQL package with nested transactions

Related Stories