WIP: Add support for pgx v5 interface

[go-jet]

No description provided.

[codecov]

Codecov Report

❌ Patch coverage is 64.24242% with 59 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.68%. Comparing base (0585cd1) to head (48b7a20).
⚠️ Report is 2 commits behind head on master.

Files with missing lines	Patch %	Lines
qrm/qrm_pgx_v5.go	57.93%	37 Missing and 16 partials ⚠️
qrm/qrm.go	73.91%	4 Missing and 2 partials ⚠️

❌ Your patch check has failed because the patch coverage (64.24%) is below the target coverage (90.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #523      +/-   ##
==========================================
- Coverage   92.18%   91.68%   -0.51%     
==========================================
  Files         139      140       +1     
  Lines        8576     8728     +152     
==========================================
+ Hits         7906     8002      +96     
- Misses        493      532      +39     
- Partials      177      194      +17     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[DevX86]

Thank you so much for this @go-jet I'm reviewing this and the adapter thread now.

[DevX86]

@go-jet

Works great so far! We may have covered this in the past but I'm trying to refresh my memory. Any reason for pgxV5.Query() instead of stmt.QueryPGX() off of the original statement builder I rather have the new one import style in your latest PR than the previous multiline qrm style but figured I'd bring it up. I believe it had something todo with a statement.go needing to be implemented but wanted to get your blessing before trying things.

---

Doing SELECT_JSON_ARR() with pgxV5.Query() works but for some reason a time.Time on a created_at is giving me the nil timestamp.
"created_at": "0001-01-01T00:00:00Z"

Generated public.table
CreatedAt postgres.ColumnTimestampz

Generated model
CreatedAt time.Time json:"created_at"``

Both are right, but including them it case TimestampTz matters. The same generated table and model work when not using SELECT_JSON_ARR() and the timestamp will be filled in.

[go-jet]

Works great so far! We may have covered this in the past but I'm trying to refresh my memory. Any reason for pgxV5.Query() instead of stmt.QueryPGX() off of the original statement builder I rather have the new one import style in your latest PR than the previous multiline qrm style but figured I'd bring it up. I believe it had something todo with a statement.go needing to be implemented but wanted to get your blessing before trying things.

The reason is because pgx is already on version 5 and what guaranties us there want be tomorrow a version 6, 7, 8 etc... I felt this pollutes statements API.

Doing SELECT_JSON_ARR() with pgxV5.Query() works but for some reason a time.Time on a created_at is giving me the nil timestamp.

Does it work with standard database/sql driver? If not, then it is probably something related to a query or a destination.
Could you share your destination?

[DevX86]

Works great so far! We may have covered this in the past but I'm trying to refresh my memory. Any reason for pgxV5.Query() instead of stmt.QueryPGX() off of the original statement builder I rather have the new one import style in your latest PR than the previous multiline qrm style but figured I'd bring it up. I believe it had something todo with a statement.go needing to be implemented but wanted to get your blessing before trying things.

The reason is because pgx is already on version 5 and what guaranties us there want be tomorrow a version 6, 7, 8 etc... I felt this pollutes statements API.

Doing SELECT_JSON_ARR() with pgxV5.Query() works but for some reason a time.Time on a created_at is giving me the nil timestamp.

Does it work with standard database/sql driver? If not, then it is probably something related to a query or a destination. Could you share your destination?

Makes sense. Though V5 Has been out for ~4 years now so not expecting a major update any time soon, having the latest PGX version under QueryPGX() wouldn't be too bad pollution wise especially if we left the legacy pgx versions as pgxV5Query() import available. At the end of the day though It's just an additional import with current usage which isn't so bad, getting it down to the one liner usage is the main goal I'll take it as a major win even if we don't do a statements.go implementation but it would be ideal!

I tried to JsonPQ version, same issue, must be something destination wise but the normal PQ/PGX versions work with the same dest which is odd.

Just doing the typical

Jet Generated Type

type News struct {
	Title     string    `json:"title"`
	Body      string    `json:"body"`
	Type      string    `json:"type"`
	CreatedAt time.Time `json:"created_at"`
	ID        uuid.UUID `sql:"primary_key" json:"id"`
}

My Custom Type

package models

import "jetpgxpoc/gen/public/model"

type News struct {
    model.News
} 

Then

stmt := postgres.
		SELECT_JSON_ARR(table.News.AllColumns).
		FROM(table.News).
		ORDER_BY(table.News.CreatedAt.DESC()).
		LIMIT(limit)

	var newsSlice []models.News // My custom type news
	if err := stmt.QueryContext(ctx, db, &newsSlice); err != nil {

We don't have to pollute this PR with this probably separate issue though.

[go-jet]

Aha I see where the issue is. SELECT_JSON statements firsts constructs a json on the db and then unmarshals the result using json.Unmarshal function. SELECT_JSON uses default golang format for json object keys - camelCase or PascalCase. But in this line:

CreatedAt time.Time `json:"created_at"

you are using snake case. So the fix is:

CreatedAt time.Time `json:"createdAt" // or `json:"CreatedAt" or you can remove json tag completely.

Also SELECT_JSON_ARR has no benefits for a statements operating on a single table. It is probably a bit slower then regular SELECT. Use it only for deeply nested destinations.

[DevX86]

Aha I see where the issue is. SELECT_JSON statements firsts constructs a json on the db and then unmarshals the result using json.Unmarshal function. SELECT_JSON uses default golang format for json object keys - camelCase or PascalCase. But in this line:

CreatedAt time.Time `json:"created_at"

you are using snake case. So the fix is:

CreatedAt time.Time `json:"createdAt" // or `json:"CreatedAt" or you can remove json tag completely.

Also SELECT_JSON_ARR has no benefits for a statements operating on a single table. It is probably a bit slower then regular SELECT. Use it only for deeply nested destinations.

Gotcha, I'll play more with it another time when optimizing complex join queries. I haven't run into any issues yet with implementing this PR into prod. Appreciate your great work as always!