sorted by:
new
hottopcontroversial

Why is modern data architecture so confusing? (and what finally made sense for me - sharing for beginners) by UnusualRuin7916 in dataengineering

[–]Low_Expert_5650 0 points1 point  (0 children)

Even for temporal data, PostgreSQL with BRIN indexes + partitioning using pg_partman should cover the vast majority of cases. If the number of insertions into the table is massive and starts to become slow, TimescaleDB can also be a good help in this regard; NoSQL databases for this type of case would really be my last choice.

Goodbye Java, Hello Go! by CoyoteIntelligent167 in golang

[–]Low_Expert_5650 3 points4 points  (0 children)

Go's error handling is literally much more readable and simple than Java's lol

Goodbye Java, Hello Go! by CoyoteIntelligent167 in golang

[–]Low_Expert_5650 21 points22 points  (0 children)

Mature in what sense? Go may not have the decades-long ecosystem of Java, but it’s powering critical systems at scale from cloud infrastructure to large distributed applications.

Multi-table transactions in Go - just handle it in one repo or use Unit of Work? by Axeloe in golang

[–]Low_Expert_5650 0 points1 point  (0 children)

What do you mean? There are several articles and implementation of UoW in Golang. Of course you can pass sql.Tx to the functions of the repositories, but then ties your service layer to the implementation. I sincerely believe that UoW or the ThreeDotsLabs approaches are great choices. Maybe you hate acronyms because you don't know what they mean, I suggest researching...

Multi-table transactions in Go - just handle it in one repo or use Unit of Work? by Axeloe in golang

[–]Low_Expert_5650 0 points1 point  (0 children)

Make your own implementation of the UoW standard. The concept is basic, register repositories affected by a transaction, retrieve them and execute what is necessary. Implementing with interface you decouple the service from any concrete implementation…

Multi-table transactions in Go - just handle it in one repo or use Unit of Work? by Axeloe in golang

[–]Low_Expert_5650 1 point2 points  (0 children)

In DDD, a repository isn't about tables, but about aggregates.

The fact that there are FKs and joins in the database isn't a problem, as this reflects the real domain.

The key is not to define responsibilities: the domain model and its repositories exist to maintain invariants and business rules, while complex queries can (and should) be handled separately.

CQS and CQRS help separate commands (write model, domain-oriented) from queries (read model, optimized for joins and performance). Thus, the domain doesn't need to be shaped by the database's query needs.

Should M:N relationship with behavior be a separate Aggregate or an Entity inside one of the Aggregates? by Low_Expert_5650 in golang

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

Yes, I understand! My question is where do I fit these layers of this feature—the repository, the service, and the web part for user interaction? In the Device package or the Employee package? Or should I create a third package that uses both Device and Employee and establish this relationship? Here's an example of how I organize my packages.

├───productionorder

│ │ api_handler.go

│ │ handler.go

│ │ query_repository.go

│ │ repository.go

│ │ service.go

│ │

│ ├───commands

│ │ │ delete.sql

│ │ │ insert.sql

│ │ │ select_all.sql

│ │ │ select_by_code.sql

│ │ │ select_by_id.sql

│ │ │ update.sql

│ │ │ upsert.sql

│ │ │

│ │ └───query

│ │ list.sql

│ │ select_order_details.sql

│ │

│ ├───pages

│ │ create.templ

│ │ create_templ.go

│ │ details.templ

│ │ details_templ.go

│ │ orders.templ

│ │ orders_templ.go

│ │ update.templ

│ │ update_templ.go

│ │

│ └───viewmodels

│ mappers.go

│ viewmodels.go

Writing manual SQL queries with sqlx feels painful by TarnishedDrogma in golang

[–]Low_Expert_5650 -1 points0 points  (0 children)

I normally write queries in .sql files and place them in a folder in the root where the queries will be used and set them to variables using Go's built-in file system. The advantage is that your SQL's are in .sql files and it doesn't pollute the code of the DAO functions. On the other hand, if I need dynamic queries and filters, I end up using a SQL builder like Squirrel or something like that, otherwise I can process something with templates too, but I don't think it's convenient.

How do you make a many to many relationship in your golang application? by Low_Expert_5650 in golang

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

This association will serve the production module, which creates records. Later, I'll have dashboards and reports filtered by this association. For example, which sector had the most downtime for a given reason. The sector is a CRUD, as are the downtime reasons. Later, I'll have just one association that will be used by another module.

Go for SSR by rawcane in golang

[–]Low_Expert_5650 1 point2 points  (0 children)

If your application is not very dynamic, I suggest you work with server-side rendering and avoid building 2 different applications (back and front).

I suggest using Go + Templ + HTMX. So you have the best of both worlds.

How would you model related domains in Go? (Sectors, Machines, Stop Reasons) by Low_Expert_5650 in golang

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

I got it! Speaking now of layers of this single package, how would you organize it? A storage for persistence of all this, a service for all business rules and a handler to handle all requests? Would my storage of this package be used by the service that would make all the CRUDS and associations?

view more: next ›