[ckan-dev] SQLite removal?

Toby Dacre toby.okfn at gmail.com
Fri Jun 14 10:15:16 UTC 2013


On 14 June 2013 10:30, David Read <david.read at hackneyworkshop.com> wrote:
>> Having Travis run the tests for us has really reduced the amount of
> times devs need to run them on their laptops.
>>
>> You still need to sometimes, of course
>
> Not running tests often is the traditional programming way. However
> many people these days write and run tests frequently. But of course
> it's OKF's perogative whether or not they support that or not.

I think what Sean is saying is that we run the tests via travis more
often than locally.
The issue is that the core developers rarely/never run the sqlite
tests and these are not run by travis

they add extra complexity to the code and dubious benefit to the core
developers who tend to run the full postgres test exclusively.

To be honest we are looking at a total review of the tests as they are
showing their vintage and have turned to a spaghetti mess over time
and really need rationalising.

It sounds like the core devs are in favour of removing sqlite and
apart from the speed issue (which does need addressing) I do not hear
any convincing argument for keeping it.

>
> Where tests rely on postgres features then we have skips for running in sqlite.
>
> Dave
>
>
> On 13 June 2013 23:33, Sean Hammond <sean.hammond at okfn.org> wrote:
>> Having Travis run the tests for us has really reduced the amount of
>> times devs need to run them on their laptops.
>>
>> You still need to sometimes, of course.
>>
>> I'd argue that the real fix for this is to write a better and faster
>> test suite. Have more unit tests and not as many functional tests, unit
>> tests are faster because they just import a module and tests its
>> functions directly, instead of testing the whole application stack.
>> Avoid unnecessarily hitting the disk, network or database in tests.
>> And let each test just run the setup code that it needs, instead of
>> having large, generic text fixtures (create_test_data) that get run
>> again and again.
>>
>> Also, making CKAN faster will make the tests faster.
>>
>> Of course this is a (very) long-term approach, sqlite is a quick gain.
>>
>> I think the problem with sqlite is we're starting to get maintenance
>> costs. People are introducing code that works with postgres but fails
>> with sqlite (and not realizing because they don't run the sqlite tests).
>> People are adding code that uses postgres features that sqlite doesn't
>> support.
>>
>> We'd have to get Travis to run the sqlite tests as well, if we want to
>> make sure they keep working. And Travis already runs the tests four
>> times for every commit with different versions of Python and Postgres.
>>
>> On Wed, Jun 12, 2013 at 02:53:17PM +0100, David Read wrote:
>>> sqlite tests were introduced purely for speed. Running all tests was
>>> taking over 10 minutes, putting developers off running them. We even
>>> had people starting to ruthlessly disable reams of key tests to make
>>> them faster! With a tuned sqlite we got it down to 1 minute for all
>>> tests - about 400 at the time I think.
>>>
>>> I use sqlite still for CKAN tests all the time. I think most of the
>>> new developers simply haven't given it a try, so here's my pitch:
>>>
>>> sqlite is perfect for TDD or anything approaching it, since the
>>> code-test turn-around time of a few tests is far quicker. In the
>>> example below, running 3 tiny tests takes 3s with sqlite and 12s with
>>> postgres.
>>>
>>> Or maybe people have found another way to run a test in a couple of seconds?
>>>
>>> David
>>>
>>> (pyenv-ckan)dread at dthink:~/gitroot/ckan$ time nosetests --ckan
>>> --with-pylons=test-core.ini ckan/tests/lib/test_munge.py
>>> ...
>>> ----------------------------------------------------------------------
>>> Ran 3 tests in 8.940s
>>>
>>> OK
>>>
>>> real 0m11.963s
>>> user 0m6.060s
>>> sys 0m0.720s
>>> (pyenv-ckan)dread at dthink:~/gitroot/ckan$ time nosetests --ckan
>>> --with-pylons=test.ini ckan/tests/lib/test_munge.py
>>> ...
>>> ----------------------------------------------------------------------
>>> Ran 3 tests in 0.365s
>>>
>>> OK
>>>
>>> real 0m3.282s
>>> user 0m2.852s
>>> sys 0m0.384s
>>> (pyenv-ckan)dread at dthink:~/gitroot/ckan$
>>>
>>> On 12 June 2013 08:53, Hendrik Bunke <bunke.hendrik at gmail.com> wrote:
>>> > Personally I love using SQLite for developing and testing
>>> > purposes. Postgresql is kind of overkill for such cases. So I'd
>>> > vote for leaving it in.
>>> >
>>> > regards
>>> > hendrik
>>> >
>>> > --On 2013-06-11 14:19, Toby Dacre wrote:
>>> >> As I understand it we can use SQLite for the tests (for some
>>> >> performance benefits)
>>> >>
>>> >> There are also some issues regarding SQLite being broken
>>> >>
>>> >> Is this something that we should continue to support?  I am not sure
>>> >> the extra maintenance is worth it - what do people think?
>>> >>
>>> >> If so shall we do this in 2.2
>>> >>
>>> >
>>> > --
>>> > Dr. Hendrik Bunke
>>> > http://gplus.to/hbunke
>>> > http://twitter.com/hbunke
>>> > http://www.hbxt.org
>>> >
>>> > _______________________________________________
>>> > ckan-dev mailing list
>>> > ckan-dev at lists.okfn.org
>>> > http://lists.okfn.org/mailman/listinfo/ckan-dev
>>> > Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>>>
>>> _______________________________________________
>>> ckan-dev mailing list
>>> ckan-dev at lists.okfn.org
>>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>>> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev



-- 
Toby Dacre

The Open Knowledge Foundation

Empowering through Open Knowledge
http://okfn.org/  |  @okfn




More information about the ckan-dev mailing list