XF 2.0 Entity has getters but not setters


Well-known member
Is there any reason in particular that XF2's Entity system doesn't support auto-magical setter wireup like it does getters?

It does support verify<camel case column>, but you can't directly intercept the <pseudo-column> set like you can with getters.

This is an oddly asymmetrical design choice.


XenForo developer
Staff member
I was going to say that there aren't a ton of situations where we would use them, though now that I think about it, I could see some use cases to simplify master phrase updating. What use cases did you have in mind? Previously, I would have noted that, without arguments, setters wouldn't be overly useful vs just setting the field directly or giving some additional context via an explicit setX() call.

Mostly I just don't think we saw an explicit need for it and it didn't push us to implement a system like it. (Of course it's also mostly syntactic sugar, so it doesn't limit anything by not having it either.)


Well-known member
I've got two situations in immediately mind;
  1. A key/value set is gathered from all columns with a similar prefix, and cached. I need to be able to invalidate the cache and then dissemble that that key/value to each column for bulk updates.
    • The use case has the fetch being call often during the page life-time, but rarely being changed.
    • Updates will virtually always be to individual columns, not the entire set.
  2. Implement transparent column-based text compression.
    • MySQL table compression has significant overheads, page compression is only supported in some versions, and transparent column compression isn't supported.
    • Getter would decompress as required from the compressed field.
    • Setter would compress (if needed) and then write the compression type to a new field and the compressed value to another field.
    • Requires ElasticSearch as MySQL-fulltext search wouldn't work with xf_post.
Last edited:


Well-known member
Any of the types at the top of Entity which match the REQUIRES_DECODING mask, so things like serialized, JSON, and the list types.

This would likely be hard to expand for an add-on (generically) due to a lot of this functionality being defined in the base entity.
I ended up prototyping this out but hit roadblocks with the Entity Manager 's getEntitySourceValue function being by-default unextendable and also not having enough context to implement compression.

I've filled a suggestion on how to change this, but otherwise it would require code edits for the cleanest solution :(