This fixes a critical bug meaning that using many_many fields in full text searching would have always failed.
the $singleton->many_many() lookup returns an array() of many-many components, however the line $class = $manyMany[0] is wrong, as the first value of the array is always the $dataClass (parentClass), not the otherClass (childClass).
Changing this to $class = $manyMany[1] fixes this bug.
MySQL is more reliable in its output ordering of elements where the order doesn't matter.
PostgreSQL is not. This meant that this test "accidentally passed" on MySQL and failed on
PostgreSQL. The sort function resolves this.
The local solr server was very out of date (because changing it would be an API change)
and took up lots of space in the repository.
This commit removes it, and references a newly created package,
silverstripe/fulltextsearch-localsolr
Not only does this save on storage space when the example server
isnt needed (you shouldnt really be using it for production), it
also disconnects the server version from the module version, so
you can easily change one without changing the other
Solr::configure_server now takes "version" as one of the keys in the
option array, and behaves slightly differently depending on whether
that version is 3 or 4, to provide support for both Solr versions.
The Solr extras and templates have also moved, so that different
versions can be provided for the two different Solr versions.
Solr_Configure takes the `indexstore.mode` configuration variable to set how
to upload new configuration to the Solr server. However the various modes
were within Solr_Configure and you couldnt add more without altering the module
This changes Solr_Configure to make the configuration upload portion
contained with a seperate class thats selected via `indexstore.mode`
to fix that.
Its impossible for SearchUpdater#handle_manipulation to figure out the difference
between writing to a table-less class (like Page if theres no $db set) and the
table-having parent (like SiteTree) because it only examines the DB manipulation
This meant if you tried to index Page without setting $db fields, only subclasses
that did have $db fields would be indexed
We cant fix, but we can throw an error if you try to do that
