almanack VS GORM

You need to add the base template to the ParseFS call. The code here is more complicated than it needs to be. You don’t need to go through the FS yourself. The template parser can do that for you. Look at this example which doesn’t use a base template but could: https://github.com/spotlightpa/almanack/blob/master/layouts/layouts.go You would just change it to

For me, GetBooks is a method on a query object and a query object has a DBTX interface struct field. So if I don’t need a transaction, I just use the normal DB as the DBTX but if I do, I call a method to open a TX first and use that. https://github.com/spotlightpa/almanack/blob/master/internal/db/db.go

Pagination is just an offset and a limit. There’s another package that handles the math for you: https://github.com/spotlightpa/almanack/blob/master/internal/paginate/paginate.go

You can have methods on the SQLC structs. They just need to be in a separate file. See https://github.com/spotlightpa/almanack/blob/master/internal/db/page.go eg.

So far, just refactoring. I made a concurrency manager to simplify some stuff, and unified some pagination code. It’s like we said before generics: there are places you miss it, but not having it was never a total blocker. I think going working the x/slices x/maps packages will be the biggest time savers.

I ended up shipping this as a similar autocomplete field: https://github.com/spotlightpa/almanack/blob/master/src/comp...

It's a little different because I put the chosen selections on a row above the input row, but the principle is the same.

https://github.com/spotlightpa/almanack/blob/master/internal/herokuapi/herokuapi_test.go#L14:L21

I’m using Chi not Gorilla, but you can see my JWT Auth middleware here: https://github.com/spotlightpa/almanack/blob/master/pkg/api/routes.go#L37

GORM is a comprehensive ORM tool in Go, offering a code-first approach which allows defining database schemas using struct tags in Go. It's known for its developer-friendly nature, making it suitable for both beginners and experienced users. GORM supports a variety of SQL databases like MySQL, PostgreSQL, and SQLite. It's designed to be flexible, allowing developers to drop down to raw SQL when necessary. However, it's important to be cautious about its performance implications in large-scale applications.

Homepage: https://gorm.io/

Since most of these APIs will be simple CRUD (Create/Read/Update/Delete) endpoints, let's build this service using GORM, an ORM library that makes building CRUD endpoints really simple.

After successfully configuring the application, it's time to delve into integrating the data layer. For this purpose, I will utilize gorm, a powerful SQL ORM that facilitates rapid development of the data layer using model structs.

For basic INSERT ... VALUES ... or SELECT ... WHERE ... JOIN ..., use a library such as GORM. For INSERT .... SELECT ... statements where one combines two round trips (SELECT and INSERT) into one, ORMs have a hard time performing this query. Particularly when you start doing joins. Joins are the heart of Relational database theory (they denote relationships). So get to know what an INNER, LEFT, RIGHT and OUTER join is and why you would use them. Also learn INSERT ... SELECT ...

I have never hated gorm and it serves me well. However I tend to feed it raw SQL very often.

Array of values with embedded value all pointed to the last value, reflect code was broken: https://github.com/go-gorm/gorm/pull/5901 data corruption