tests suite for django solr

[GoogleCodeExporter]

This is not really a bug request but rather and enhancement that I have
been thinking while working with solango.

In fact I have been thinking of what would be the best approach to test
solango. In fact the fact that the library is not doing much alone make it
difficult to test. I had a similar issue with django-geotagging and I
resolve it by adding a "demo_project" to the repository and a dummy test
django app that contains a models that will be used to exercise the main
reusable app (solango in this case).

I see several advantage at using such layout. It gives you a way to ship a
workable example demonstrating your application. Allow you to test your
application in a control environment and thus help to build an extensive
test suite. The test of solango will not pollute the solr index of the
project it is integrated with.

I would be glad to hear from you on this topic.

django-geotagging : https://launchpad.net/django-geotagging 

--yml

Original issue reported on code.google.com by yann.ma...@gmail.com on 14 Feb 2009 at 1:47

[GoogleCodeExporter]

In my haste to get some community feedback I excluded tests, but I definitely 
agree
with you that they need to be added.

You are right in that if you know nothing about the Solr schema it's impossible 
to
test anything but whether Solr is available or not. I started a demo app called
example, but it was never finished. I think the docs should be moved out of 
solango
as well. 

I like the way you structured geo-tagging, solango could definitely benefit from
this. I can take a stab at it.

Thanks,

Sean

Original comment by sean.cre...@gmail.com on 16 Feb 2009 at 3:04

[GoogleCodeExporter]

Sean,

I let you take a stab at it since there is a lot of opinion going into this 
kind of
project organization.

Regards,

--yml

Original comment by yann.ma...@gmail.com on 19 Feb 2009 at 2:46

[GoogleCodeExporter]

Hi,
I've been using this app and it's great, I've done up test cases that can be 
run with
the command
python manage.py test solango

the only requirements are that you must have:
1. An existing SOLR_ROOT that contains the jetty start.jar
2. TEST_RUNNER='solango.tests.run_tests'
in settings.py

The attached tar.gz contains the tests directory that can be dropped in to the
solango app.
The test directory contains a standalone default Solr configuration.
When you run the tests it unregisters existing search apps and registers an 
included
testblog application (straight from the existing documentation).
This app is then used for some very basic tests (just to get a start).
All data is deleted at the start of each test run and you are prompted with the
command line required to restart Solr.  If you use the command line that you are
prompted with all data will be stored in your tests directory (otherwise it may
delete your production data directory, so be careful).
Thanks
Michael

Original comment by michael.thornhill on 24 Mar 2009 at 12:22

Attachments:

• solango_tests.tar.gz

[GoogleCodeExporter]

Excellent. Thank you for doing this. I will try to test it out later tonight.

I probably won't add the solr dir though. I don't want to tie solango to one 
version
of Solr.

Original comment by sean.cre...@gmail.com on 24 Mar 2009 at 1:47

[GoogleCodeExporter]

Hi Sean,
That sounds like a good idea about the Solr version, one other thing I forgot to
mention was that it was necessary for me to create a blank models.py in the 
solango
directory in order to be able to run the tests (django-svn 1.0.3).
Thanks
Michael

Original comment by michael.thornhill on 24 Mar 2009 at 3:08

[GoogleCodeExporter]

hi
in your test suite, your search.py has:
 settings.INSTALLED_APPS.append('solango.tests.testblog')
It does not compile for me. INSTALLED_APPS happens to be a tuple...

Original comment by badri.di...@gmail.com on 3 May 2009 at 2:24

[GoogleCodeExporter]

Hi Badri, Sean,
This version of the test cases has the following improvements
1. settings.INSTALLED_APPS is converted to a list to allow appending of test 
model
2. existing solr server is used (solango not tied to a version of Solr)
3. Solr server is started and stopped automatically by the test runner
4. The indexed data is stored in solango/tests/solr/data so it doesn't 
overwrite any
existing indexed data

the only requirements are that you must have:
1. An existing SOLR_ROOT that contains the jetty start.jar
2. TEST_RUNNER='solango.tests.run_tests'
in settings.py

Thanks,
Michael

Original comment by michael.thornhill on 31 Jul 2009 at 3:05

Attachments:

• solango_tests_v2.tar.gz

[GoogleCodeExporter]

Finally had some time to give this a decent look over. Mostly very good code. 
I've cleaned up a couple of things:

 - use solango.logging and stdout/stderr rather than creating yet another log file just for tests

 - allow the solr test path to be overridden with settings.SOLR_TEST_PATH (as the default test data dir is not necessarily writable)

Does anyone know a way to start the solr server with a custom schema.xml rather 
than using the production one? This seems kind of necessary, especially as 
there's 
no easy way to create a schema.xml for the testblog app manually. Am I missing 
something?
Naive way is to backup the original schema.xml, then create a new one, then put 
the original back afterwards, but that's kind of ugly.

I'm keen to commit this soonish, once we've addressed the schema.xml problem, 
ugly or otherwise.

Original comment by craig.ds@gmail.com on 14 Sep 2009 at 11:08

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

Attachments:

• solango_tests_v2.1.patch

[GoogleCodeExporter]

Original comment by craig.ds@gmail.com on 14 Sep 2009 at 11:08

[GoogleCodeExporter]

A more fundamental problem arises if you want to test things like a subclassed
indexer, programmatically change indexers in mid-stream, or use a different 
core for
running test cases.

As soon as django imports solango as an installed app, the connection object is
initialized, all of the models are registered and django's setting module is 
loaded
into every nook and cranny.

run_tests is fired off by django after this point, so swapping out the solango
settings in settings or solango.settings won't help.

Creating the connection to the solr server should be delayed until it is needed 
or
explicitly called, and model registration should happen after that (though this 
last
one can be resolved using custom models for the unit tests and registering them
manually).

I guess another option is to provide a method to reset solango's connections, 
reload
the settings modules and re-create the connection singleton.

Original comment by georged...@gmail.com on 15 Oct 2009 at 10:32

[GoogleCodeExporter]

My team has made a number of patches locally to solango to defer autodetection 
of 
models and initialization of the connection until an indexer is actually 
needed. The 
first portion of this is in a patch on issue #58, but we have continued to 
identify 
places in the solango code where objects are bound too eagerly and changed them 
to work on-demand. I've have implemented a batching background indexer which 
processes updates in a background thread, which we have found greatly speeds up 
bulk import and test suite execution.

I would be happy to prepare a unified patch covering these changes for review 
if it 
was of interest, but am unsure whether to provide it in this comment thread, 
the one 
for #58, or in a new ticket entirely.

Original comment by rco...@gmail.com on 21 Oct 2009 at 10:10

[GoogleCodeExporter]

The fundamental way that solango is going to handle indexing/batch indexing is 
going
to change. I've started to rewrite this aspect over on github
(http://github.com/screeley/solango/tree/screeley/solango/). I'm looking for 
feedback
on this changes. They include multiple indexes, deferring objects for bluk 
loading
and just better performance. I recommend starting to look at those changes and 
see
how they impact you. 

I to don't like how the indexing works right now. I need a few more days to get 
more
code out there, but it's a start.

Original comment by sean.cre...@gmail.com on 21 Oct 2009 at 10:30

[GoogleCodeExporter]

I've created a fork of the GitHub project, and will continue my own experiments 
there. 
Thanks, Sean.

Original comment by rco...@gmail.com on 21 Oct 2009 at 11:38