Replies: 2 comments
-
It's a fair point. I've actually been wondering if we could get rid of the ObjectState entirely, since it's overall a bit gross to be generating a struct field. Since #117 it's only really been used for auto-primary-key situations. I've been thinking about whether there's a cleaner way to approach those. Let me update further tomorrow. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Closing this as ObjectState was removed in #151 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
I have a problem with the name chosen for the butane::ObjectState member added by butane.
I would like to use butane to record finite state machine objects and state is such a good and common field name, that I find it sad that it is forbidden due to the butane crate.
It looks to me that it could be far better for users that, added members by macros, got names that will be very very unlikely to conflict with field names likely to be chosen by programmers.
What about something like _butane_orm_state ?
It would be even better to add some digits or cryptic code to make it even more unlikely to conflict (butane + orm is safe enough in my opinion however).
It happens that in my company, we had worked for a fuel transporter and comically I have found in my old code a butane_state variable somewhere ...
I hope this discussion is not too pedantic.
The change, I call for, will obviously break some code, which will require a major version change, but I think it is worth doing it as the earliest, for the very reason that no new user will be impacted by this change.
Beta Was this translation helpful? Give feedback.
All reactions