XF 2.0 Entity has getters but not setters

[Xon]

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.

 

[Mike]

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

 

[Xon]

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.

 

[Xon]

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