- πΊπΈUnited States tr Cascadia
Are you going to work on this?
I don't see anything compelling that argues for making this simple data into entities. There's absolutely nothing "wrong" with storing this data in tables, and entities are a remarkably heavy-weight solution. But if you want to do the work, along with creating update hooks and test cases, then that's something I will consider. Before you do that, however, please explain why you think converting to entities will be "better".
- πΊπΈUnited States devkinetic
There were a few reasons, trying to remember as this was now 3 years ago. Stuff like access to the entity api, entity listings, having the codes be accessible to views. Pretty much normalizing it with the rest of the Drupal ecosystem. I don't disagree that entities are heavier weight than a plain custom table, but it does limit the flexibility a developer is used to having when interacting with the table.
I think, at the time, I was using the group module, and I wanted a field reference to link a group with a reg code. So a group admin could manage the code(s) for their group, see which members used which code, etc. Since reg codes were decoupled, I had to custom code the entire thing, rather than just linking things up and doing things within the entity system.
- Status changed to Active
2 months ago 4:38am 4 September 2024 - πΊπΈUnited States tr Cascadia
I'm warming to the idea, but as a first step I want to create a real first-class object to represent a regcode, rather than basing everything on \stdClass with dynamically created (and untyped, and unchecked) properties. Plus tests of course to make sure the object works properly.
After that is should be pretty easy to substitute an Entity, because we'll have all the typing and testing in place and if there's a mistake it will break something.