As designed Indexing bypasses entity getter methods

[Xon]

Affected version

2.0 Beta 1

Most of the Search data handlers explicitly bypass entity getters when accessing title/messages. None of these have a getter by default, so the stock extra cost is 1 extra boolean check.

This would just cause surprises if an add-on later implements a getter on these.

Using the regex;

->[a-zA-Z]+_[;,\s]

These matches are entity getters, so it is expected they are using this;

src\XF\Entity\SessionActivity.php (1 hit)
    Line 12:         $params = $this->params_;
src\XF\Entity\SpamTriggerLog.php (1 hit)
    Line 14:         foreach ($this->details_ AS $detail)

But these search handlers use it;

src\XF\Search\Data\Post.php (1 hit)
    Line 44:             'message' => $entity->message_,
src\XF\Search\Data\ProfilePost.php (1 hit)
    Line 34:             'message' => $entity->message_,
src\XF\Search\Data\ProfilePostComment.php (1 hit)
    Line 34:             'message' => $entity->message_,
src\XF\Search\Data\Thread.php (2 hits)
    Line 38:             'title' => $entity->title_,
    Line 39:             'message' => $firstPost ? $firstPost->message_ : '',

 

[Xon]

Ah, after a bit more digging this is related to the auto-'censor'ing for these fields. Yuck.

 

[Mike]

As noted, there are legitimate reasons for this (though we don't inherently need it on message right now). Equally, there are plenty of places that pull getValue which doesn't use getters either. Accessing fields without getters always needs to be allowed/accepted.

At a guess, I'm assuming this might be related to you considering invisible compression on these fields, which would fundamentally change what's stored in the DB in a given column. Any add-on fundamentally changing content like this is going to be difficult. This is really something that would need to be handled at a lower level than a getter. This is more similar to one of our complex column types which means all the processing is handled invisibly to you, regardless of access patterns.

 

[Xon]

This is more similar to one of our complex column types which means all the processing is handled invisibly to you, regardless of access patterns.

Do you have an example of this off-hand?

 

[Mike]

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.