Add ability to define fields as arrays. This is only implemented for the driver pgx. This is the way to declare it:
model user (
key id
field pet_names string ( array, updatable )
)
The change does not introduce a syntax with brackets because the feature is probably used too rarely to warrant introducing new tokens. (in general I think the drawbacks of DSL's like DBX usually outweight the benefits vs expressing it in the host language, in this case Go).
An array in Go is always nullable, so there is no pointer to array if the field is nullable on the SQL side. The generated code takes care to distinguish between nil and an empty array.
When reviewing, please consider whether changes are in the right place. The codebase is unfamiliar to me and it has few comments to guide the developer. Making this change felt like a blind man touching an elephant.
This change exposes/introduces some shortcomings in the approach to generate code, but it is functional. It can work as a starting point to improve those.
A follow-up on this change would be to add a way to atomically append to an array.
Another addition would be support for length and dimensions. We can think of how to add these attributes while adhering to the rules and spirit of the current syntax. Postgres supports these attributes but does not enforce that the data conforms to them. Example idea:
model user (
field my_array int (
array(dimensions 2 length (3 2))
updatable
)
)
Add ability to define fields as arrays. This is only implemented for the driver pgx. This is the way to declare it:
The change does not introduce a syntax with brackets because the feature is probably used too rarely to warrant introducing new tokens. (in general I think the drawbacks of DSL's like DBX usually outweight the benefits vs expressing it in the host language, in this case Go).
An array in Go is always nullable, so there is no pointer to array if the field is nullable on the SQL side. The generated code takes care to distinguish between nil and an empty array.
When reviewing, please consider whether changes are in the right place. The codebase is unfamiliar to me and it has few comments to guide the developer. Making this change felt like a blind man touching an elephant.
This change exposes/introduces some shortcomings in the approach to generate code, but it is functional. It can work as a starting point to improve those.
A follow-up on this change would be to add a way to atomically append to an array.
Another addition would be support for length and dimensions. We can think of how to add these attributes while adhering to the rules and spirit of the current syntax. Postgres supports these attributes but does not enforce that the data conforms to them. Example idea:
Change moved from https://review.dev.storj.io/c/storj/dbx/+/9297 to GitHub. Open feedback has been addressed.
Run tests using
docker-compose run gotestChange-Id: If773dc1c900b31dfe321d3d0172361b98c79451d