I've given this a ponder and there may be a workaround, although I'll
need Pat or someone else with a better knowledge of Sphinx internals
to weigh in.
Are there any disadvantages to moving from something like this:
Page.class_eval do
include IndexDefinition
end
...to something like this?
[Page, *Page.subclasses].each do |klass
klass.class_eval do
include IndexDefinition
end
end
This way any pre-loaded subclasses get the behavior as well, but I'm
not sure if defining multiple indexes like this will interfere with
TS's own subclass handling.
Any insight?
Thanks,
j
On Jan 8, 2:09 pm, Josh French <[email protected]> wrote:
> > Any chance to change the code of sphinx-search in a
> > way to get rid of at least one of those requirements
>
> Not really, unfortunately. I'd just end up creating the same kind of
> load-order problem for someone else's extension. In your case, you
> could do:
>
> config.extensions = [:sphinx_search, :all, :file_system]
>
> What's important is that sphinx_search get loaded before any
> extensions that add Page subclasses, not that it come strictly first.
> So you've got some leeway in how you order your extensions.
>
> j
--
You received this message because you are subscribed to the Google Groups
"Thinking Sphinx" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/thinking-sphinx?hl=en.
