Add support for embedded no anonymous fields

[Andrii Savytskyi]

Change

// struct without primary key is a field
// TODO: test by scanner/valuer instead?
if pk, _ := searchPrimary(typ); len(pk) == 0 {
	data.fields = append(data.fields, name)
	continue
}

If struct implement scanner/valuer - is field, else is embedded

[Surya Asriadie]

Hi, thanks for posting this issue

can you elaborate more about what you want to do?

[Andrii Savytskyi]

can you elaborate more about what you want to do?

Embeddable :)

type Price struct {
	Amount f64
	Currency string
}

type Product struct {
	ID int
	Title string
	Price Price
}

Table:

id
title
price_amount
price_currency

[Surya Asriadie]

I see, that make sense
I guess for the API, we need to declare it as embedded explicitly using struct tag

following existing convention: https://go-rel.github.io/basics/#embedded-structs
I think following combination is possible:

• db:"product_,embedded": field will be prefixed with product_
• db:",embedded": field won't be prefixed

note: embedded structag is required for named embedding

what do you think? (and let me know if you are willing to send a PR for this 😄 )

[Andrii Savytskyi]

What are the reasons why a structag is needed? In the current API we can detect is embedded or association or custom type(valuer)

[Surya Asriadie]

one reason is for explicitness, so other people who read the code can know that it's an embedded field without guessing or looking deep to the documentation

another reason is this idea can be expanded in the future, we can have another utility tag beside embedded to do something else. for example db:",embedded_json" tag to encode/decode the field as json text

[Andrii Savytskyi]

other people who read the code can know that it's an embedded field without guessing or looking deep to the documentation

But for association this rule does not work:

type User struct {
    Address Address // association or custom type(valuer) ?
}

[Surya Asriadie]

that's right,

but I think we can see association as default behavior. when there's a field with struct type (except time), it's easier to think it's as association at first
where for embedded object, we need to check the content of struct first, and maybe some people may also add comment to the field declaration

type Product struct {
	ID int
	Title string

        // prefer people to do (2) rather than (1)

        // embedded field of price_*                    <- (1)
	Price Price

        Price Price `db:"price_,embedded"`          <- (2)
}