You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the code was generated with v1.10, the left join struct was as follows :
type GetItemByUniqueIdentifierRow struct {
ID int64
UniqueIdentifier string
Title string
Content string
MetadataID sql.NullInt64
MetadataRate sql.NullInt64
ID_2 sql.NullInt64
Rate sql.NullInt64
Name sql.NullString
ItemID sql.NullInt64
}
When the code was generated with v1.11
type GetItemByUniqueIdentifierRow struct {
ID int64
UniqueIdentifier string
Title string
Content string
MetadataID sql.NullInt64
MetadataRate sql.NullInt64
ID_2 int64
Rate int64
Name string
ItemID int64
}
You can see that the joined table fields (Rate, Name, ItemID..), should have Null* types but when used with v1.11 this fields seem like non-nullable(int64 instead of NullInt64).
In fact, when doing left join, if we use alias, it detects nullable fields correctly, if we do not use it and we say that it takes all columns like c.* without using alias, it shows the fields of the join table incorrectly.
If we look at the join query, the alias was used for the id and rate fields of the joined table, and these fields became nullable when the code was generated. It is true.
When we use c.* to get all columns of the joined table, all fields are generated as non-nullable. There seems to be a bug here about using c.*
SQL tables and go models are below.
Relevant log output
No response
Database schema
CREATETABLEitem_metadata (
id bigserialPRIMARY KEY,
name TEXTNOT NULL DEFAULT '',
rate BIGINTNOT NULL,
item_id BIGINTREFERENCES items (id) ON DELETE CASCADE
);
CREATETABLEitem (
id bigserialPRIMARY KEY,
title TEXTNOT NULL DEFAULT '',
content TEXTNOT NULL DEFAULT '',
unique_identifier TEXTNOT NULL,
UNIQUE(unique_identifier)
);
-- name: GetItemByUniqueIdentifier :oneSELECT t.*,
c.idas metadata_id,
c.rateas metada_rate,
c.*FROM item t
LEFT JOIN item_metadata c ONc.item_id=t.idWHERE unique_identifier = $1;
Go models :
type item struct {
UniqueIdentifier string
Title string
Content string
ItemMetadata *metadata.ItemMetadata
}
type ItemMetadata struct {
Name string
Rate int
}
SQL queries
-- name: GetItemByUniqueIdentifier :oneSELECT t.*,
c.idas metadata_id,
c.rateas metadata_rate,
c.*FROM item t
LEFT JOIN item_metadata c ONc.item_id=t.idWHERE unique_identifier = $1;
Configuration
No response
Playground URL
No response
What operating system are you using?
macOS
What database engines are you using?
PostgreSQL
What type of code are you generating?
Go
The text was updated successfully, but these errors were encountered:
damla-unal
changed the title
When upgrade to 11.1.0, nullable fields not correct in left join
When upgrade to 1.11.0, nullable fields not correct in left join
Dec 20, 2021
Version
1.11.0
What happened?
When work with v1.10, left join is run correctly.
When the code was generated with v1.10, the left join struct was as follows :
When the code was generated with v1.11
You can see that the joined table fields (Rate, Name, ItemID..), should have Null* types but when used with v1.11 this fields seem like non-nullable(int64 instead of NullInt64).
In fact, when doing left join, if we use alias, it detects nullable fields correctly, if we do not use it and we say that it takes all columns like c.* without using alias, it shows the fields of the join table incorrectly.
If we look at the join query, the alias was used for the id and rate fields of the joined table, and these fields became nullable when the code was generated. It is true.
When we use c.* to get all columns of the joined table, all fields are generated as non-nullable. There seems to be a bug here about using c.*
SQL tables and go models are below.
Relevant log output
No response
Database schema
SQL queries
Configuration
No response
Playground URL
No response
What operating system are you using?
macOS
What database engines are you using?
PostgreSQL
What type of code are you generating?
Go
The text was updated successfully, but these errors were encountered: