No issue: syntax changes only. None of this is necessary.
While working on CaseContacts, I noticed the status enum was defined oddly. I started poking around. The enum is used to define .active?/.started? and not much else - doesn't use any of the other methods or scopes that come along with an enum definition. It is also a string column, which is atypical. That is for easy compatibility with the wicked wizard form steps - but standard integer column would make for faster queries.
What changed, and why?
The main thing I wanted to do is define the enum in a way that makes sense. But then I kept going to see if we could better use the enum, and set things up for a transition to integer column. That won't be necessary until performance is a real-world concern. It would require migrating existing data, which could be delicate. But these changes would enable it. The definition & wizard form updates would work if the enum column was changed to an integer type.
Explicitly define the enum (If this is all you want to do here, I'm happy with that)
Use the methods and scopes that are defined by doing so
Integrate those changes into the wizard step updates
Integrate the enum into factories
How is this tested? (please write tests!) 💖💪
Current specs. Could add/modify specs for each of the enum-created scopes, will probably look at that a bit, especially if people want to do this. I think the scope changes in specs are enough?
What github issue is this PR for, if any?
No issue: syntax changes only. None of this is necessary.
While working on CaseContacts, I noticed the status enum was defined oddly. I started poking around. The enum is used to define
.active?/.started?and not much else - doesn't use any of the other methods or scopes that come along with an enum definition. It is also a string column, which is atypical. That is for easy compatibility with the wicked wizard form steps - but standard integer column would make for faster queries.What changed, and why?
The main thing I wanted to do is define the enum in a way that makes sense. But then I kept going to see if we could better use the enum, and set things up for a transition to integer column. That won't be necessary until performance is a real-world concern. It would require migrating existing data, which could be delicate. But these changes would enable it. The definition & wizard form updates would work if the enum column was changed to an integer type.
How is this tested? (please write tests!) 💖💪
Current specs.
Could add/modify specs for each of the enum-created scopes, will probably look at that a bit, especially if people want to do this.I think the scope changes in specs are enough?