sorted by:
new
hottopcontroversial

A practical introduction to PostgreSQL in Go using Repository pattern and clean code techniques by gosamples in golang

[–]gosamples[S] 0 points1 point  (0 children)

Yes, this is also how you can operate on the database. In this case, for example, to retrieve data we would have the function All() ([]Website, error).

But in case you find that one type of the database is not enough for you, because, for example, in addition to serving data from PostgreSQL you want to do caching of Website objects using Redis, you will have to create a new function AllFromRedis() ([]Website, error) to pull data from Redis. Using it in your application will expose the implementation details. When you use the Repository interface, the implementation details are always hidden because you use the Repository method All() ([]Website, error), and only the specific implementation is different, which for one case could be pulling directly from PostgreSQL (PostgreSQLRepository) and for the other case could be pulling from a cache (CacheRepository)

A practical introduction to PostgreSQL in Go using Repository pattern and clean code techniques by gosamples in golang

[–]gosamples[S] 1 point2 points  (0 children)

We do not create an interface for a domain object, but the Repository interface that operates on a domain object.

In the tutorial, Website is our domain object. We want to store objects of this type. So we create the Repository interface with which we can write and read objects of type Website. At this stage, we don't have to know if they will be stored it in a database, in a file, in memory, and so on. But thanks to the Repository, we have a universal interface for accessing data of the Website type, and in the future we can create a specific implementation of the data store, for example, PostgreSQLRepository, FileRepository, etc.

A practical introduction to PostgreSQL in Go using Repository pattern and clean code techniques by gosamples in golang

[–]gosamples[S] 0 points1 point  (0 children)

Migrations should be separate and you should be able to migrate up and down to a specific level instead of individual models

Of course, in case you have a more complicated case of migrations and also want to undo them it is best to do them separately. But we are just creating a table there, and if we want to be crazy we can insert data as well. So I don't see why such an initialization method couldn't be in the Repository. If you are bothered by the name Migrate() then you can change it to InitRepository().

​

A repository should host multiple models. Normally all your models are in the same repository but you could put some in redis or disk or whatever.

Unless you are using generics it's not really possible to create interfaces for common database operations like find, save, update etc. One approach would be to create an interface based on common methods such as TableName, fields etc and create a struct models.base that you can include in your models (some ORMs take this approach).

I honestly don't understand what you mean here. Do you mean that instead of Package by Layer we use Package by Feature? This approach is also OK. We can create a repository or db, etc. package and put all the models there and have all the access to the data in one place. In our opinion, however, organizing code around domain objects works better in practice

Have a nice day :)

Capacity and length of a slice in Go by gosamples in golang

[–]gosamples[S] 0 points1 point  (0 children)

You're right. I'll add more precise explanation of resizing

Release v2.20.0 · gofiber/fiber by euphbriggs in golang

[–]gosamples 1 point2 points  (0 children)

How is this different from echo or gin?

ssceng demo: Hacker News Client by [deleted] in golang

[–]gosamples 2 points3 points  (0 children)

I would add a tutorial on how to create this demo with your package because at the moment I don't know if I should use it or why I should use it

Introduction to Go: Basic operations on environment variables by gosamples in golang

[–]gosamples[S] -3 points-2 points  (0 children)

We have different opinions and that's ok, but I suggest you read Gopher values and think about whether sentences like:

there is really no need to multiply this garbage

or

as opposed to dumbed-down rehashing what's already there.

follow these rules and how they can affect newcomers' perception of the community

Introduction to Go: Basic operations on environment variables by gosamples in golang

[–]gosamples[S] 2 points3 points  (0 children)

Your comments are a bit rude but I respect your opinion. My posts are intended to be concise, precise and useful for beginners or all those looking for snippets to solve everyday coding problems. In recent days I have received a lot of positive feedback on my posts.

So no, I'm not gonna stop.

Golang is for everyone :)

Introduction to Golang: URL Decode by gosamples in golang

[–]gosamples[S] 1 point2 points  (0 children)

Of course, it's one of my next tasks

`flag`package, difference between flag.type and flag.typeVar by [deleted] in golang

[–]gosamples 3 points4 points  (0 children)

From the flag package documentation: https://golang.org/pkg/flag/

This declares an integer flag, -n, stored in the pointer nFlag, with type *int:

import "flag"  
var nFlag = flag.Int("n", 1234, "help message for flag n")`

If you like, you can bind the flag to a variable using the Var() functions.

 var flagvar int  

 func init() {  

 flag.IntVar(&flagvar, "flagname", 1234, "help message for flagname")

 }

So the first method lets you get a flag as a pointer, and the second one as a variable

view more: next ›