bob icon indicating copy to clipboard operation
bob copied to clipboard

Name clash in tables with newest release

Open sweigert opened this issue 1 year ago • 4 comments

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!

sweigert avatar Nov 22 '24 10:11 sweigert

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 avatar Nov 22 '24 12:11 stephenafamo

@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.

mbezhanov avatar Feb 03 '25 16:02 mbezhanov

Perhaps.

But we need to consider the other possible constants that may be useful to generate names for.

  • Index names
  • constraint names
  • errors

stephenafamo avatar Feb 03 '25 16:02 stephenafamo

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.

mbezhanov avatar Feb 04 '25 09:02 mbezhanov