Closed ClayChipps closed 4 years ago
Author of the original version of QueryFactory here: it was just never a priority to implement. The use cases that initially drove the creation of QueryFactory stemmed from a LOT of work building complex SOQL uilti-fieldset queries dynamically. There wasn't a need for doing that with SOSL - the use cases there tended to be less dynamic-at-runtime (at least for me), so it just was a priority.
The returning fields across multiple types on SOSL might be a challenge to wrangle, but thinking through it I can't see any hard blockers other than it being a fair bit of work. I'd be a little worried about the performance of trying to validate especially complex SOSL queries since they might span so many objects and fields.
@capeterson Yea that makes sense to me, and agree with you on the SOSL tends to be less dynamic than SOQL when building. Good to know that it was a case of priorities as opposed to difficulty, I may end up taking a stab at building some of this out. I can see it being useful if only for the purpose of object-orienting the creation a bit. Thank you for the insight!
Does it make sense to implement methods to the fflib_QueryFactory to support the creation of SOSL searches? We have been implementing fflib into many of our projects, but always end up putting regular old SOSL statements into the selector class, without being able to apply FieldSets or default fields to those searches easily.
I was curious if there was a reason SOSL had never been worked into the QueryFactory, or if it was simply never taken on up to this point. I would be interested in working to implement this functionality, but wanted a sanity check before I ran off doing something that had already been looked into.