Name clash in tables with newest release
Hi,
I was upgrading to the latest release but I get an error in the generated code. It is related to how the variables are named in the generated models since it generated an error variable for the unique constraints which seems to follow the naming pattern <TableName>Errors.
But if you actually have a table, called device_errors it will also translate to DeviceErrors.
Here is a minimal example:
CREATE TABLE devices (
id UUID,
id2 UUID,
PRIMARY KEY (id)
);
CREATE TABLE device_errors (
id UUID,
PRIMARY KEY (id)
);
ALTER TABLE devices ADD CONSTRAINT unique_devices UNIQUE (id, id2);
The generated code cannot compile since DeviceErrors will be defined multiple times.
Btw, I am really enjoying bob. Thanks for your work!
Not good 😬 . I'll think of some ideas to prevent this in the future.
Temporarily, consider adding an alias for device_errors so that it is generated with a different name.
@stephenafamo Would it help if the constants resided in a separate package? (e.g., models/errors?)
In that case, the models folder could assume a similar structure:
models
├── bob_main.go
├── bob_main_test.go
├── errors
│ └── devices.go
├── devices.go
└── devices_test.go
The client code could change as follows:
package main
import (
"myproject/models"
"myproject/models/errors"
// other imports go here
)
// code that raises errors goes here
if errors.Devices.ErrUniqueDeviceIds.Is(err) {
// handle the error
}
This is a breaking change but would resolve the issue described by @sweigert.
I can prepare a PR for this if you're happy with the proposal.
Perhaps.
But we need to consider the other possible constants that may be useful to generate names for.
- Index names
- constraint names
- errors
If you agree with the idea of using a separate package, it could be a more generic one, such as models/constants. The package could then encapsulate all names that it's useful to have constants defined for.