Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support custom field types #7

Open
egonelbre opened this issue Sep 7, 2023 · 4 comments
Open

support custom field types #7

egonelbre opened this issue Sep 7, 2023 · 4 comments

Comments

@egonelbre
Copy link
Member

Currently there's significant amount of code that's being written to convert from []byte to uuid.UUID, because dbx doesn't seem to allow specifying custom types.

@zeebo
Copy link
Collaborator

zeebo commented Sep 8, 2023

this would be great. an easy but janky way to do it is to require that the type not have any .s in it (because the parsing is harder) and allow any type for the field and use aliases. for example, just allow field foo uuid and add a type uuid = uuidpkg.UUID into the package somewhere.

i think the code gen needs to know how to create a zero value, but actually it could always have done *new(T) for any T like we do with generics now.

@egonelbre
Copy link
Member Author

Maybe:

model baz (
	field id bytea ( default 50, type "storj.io/common/uuid.UUID" )
)

But, this should work as well, most of the time

model baz (
	field id bytea ( default 50, type storj.io/common/uuid.UUID )
)

@egonelbre
Copy link
Member Author

egonelbre commented Sep 8, 2023

One option would be to allow specifying custom types,e.g.

type StorjUUID (
    sqlite   text
    postgres bytea
    go       storj.io/common/uuid.UUID
)

model baz (
	field id StorjUUID ( default 50 )
)

@zeebo
Copy link
Collaborator

zeebo commented Sep 8, 2023

i think the quoted version would be easiest to support with the current parser. also, this works nicely as long as conversions are applicable, but uuid is a special case where it isn't.. more info or a convention is required for handling non-convertable types.

and your go directive in the type means this is a bit more complicated than i thought. maybe it's time to just drop hypothetical other languages as a feature because it hasn't materialized in 7 years lol.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants