lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Steffensen (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-4114) Collection API: Allow multiple shards from one collection on the same Solr server
Date Wed, 05 Dec 2012 13:48:59 GMT

    [ https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510471#comment-13510471
] 

Per Steffensen edited comment on SOLR-4114 at 12/5/12 1:47 PM:
---------------------------------------------------------------

Guess there are two "movements" in the industry at the moment
* TDD: Mostly focused at testing "units" (single components), hoping that if all "units" work
as they are supposed to, the entire system where all those "units" are used in combination
will also work as it is supposed to
* BDD: Mostly focused at testing "behaviour" of a system seen from the outside, because that
is basically all you care about. No one cares how the system works internally. Everyone cares
about how the system works as a whole, when used to the extend you can use it "from the outside".
This is especially true for the end users of the system, and at the end of the day a system
is created to fullfil the users needs.

bq. Integration-level tests aren't nearly as useful

I completely disagree with that.

I, personally, are not that much into "unit"-tests because thay basically do not show that
the system as a whole "behaves" as it is supposed to. Behavioural/integration-tests does,
where you test against an entire system using it the way it can be used "from the outside",
and asserting that "result" is as expected seen "from the outside".

bq. and much more difficult to debug

You are right about that. I like "unit"-tests to supplement behavioural/integration-tests
whenever it is found to be necessary. We can add a OverseerCollectionProcessor "unit"-test,
testing some of this new functionality, but in my mind (as I said) "it will not ensure the
correct system-level functionality to nearly the same degree", and basically thats all we
are interrested in.

If the community would like we can supplement with "unit"-tests for this new feature, but
you will have to fight me (FWIW) to get rid of the integration-ish test of the feature.
                
      was (Author: steff1193):
    Guess there are two "movements" in the industry at the moment
* TDD: Mostly focused at testing "units" (single components), hoping that if all "units" work
as they are supposed to, the entire system where all those "units" are used in combination
will also work as it is supposed to
* BDD: Mostly focused at testing "behaviour" of a system seen from the outside, because that
is basically all you care about. No one cares how the system works internally. Everyone cares
about how the system works as a whole, when used to the extend you can use it "from the outside".
This is especially true for the end users of the system, and at the end of the day a system
is created to fullfil the users needs.

bq. Integration-level tests aren't nearly as useful

I completely disagree with that.

I, personally, are not that much into "unit"-tests because thay basically do not show that
the system as a whole "behaves" as it is supposed to. Behavioural/integration-tests does,
where you test against an entire system using it the way it can be used "from the outside",
and asserting that "result" is as expected seen "from the outside".

bq. and much more difficult to debug

You are right about that. It like "unit"-tests to supplement behavioural/integration-tests
whenever it is found to be necessary. We can add a OverseerCollectionProcessor "unit"-test,
testing some of this new functionality, but in my mind (as I said) "it will not ensure the
correct system-level functionality to nearly the same degree", and basically thats all we
are interrested in.

If the community would like we can supplement with "unit"-tests for this new feature, but
you will have to fight me (FWIW) to get rid of the integration-ish test of the feature.
                  
> Collection API: Allow multiple shards from one collection on the same Solr server
> ---------------------------------------------------------------------------------
>
>                 Key: SOLR-4114
>                 URL: https://issues.apache.org/jira/browse/SOLR-4114
>             Project: Solr
>          Issue Type: New Feature
>          Components: multicore, SolrCloud
>    Affects Versions: 4.0
>         Environment: Solr 4.0.0 release
>            Reporter: Per Steffensen
>            Assignee: Per Steffensen
>              Labels: collection-api, multicore, shard, shard-allocation
>         Attachments: SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch,
SOLR-4114_trunk.patch
>
>
> We should support running multiple shards from one collection on the same Solr server
- the run a collection with 8 shards on a 4 Solr server cluster (each Solr server running
2 shards).
> Performance tests at our side has shown that this is a good idea, and it is also a good
idea for easy elasticity later on - it is much easier to move an entire existing shards from
one Solr server to another one that just joined the cluter than it is to split an exsiting
shard among the Solr that used to run it and the new Solr.
> See dev mailing list discussion "Multiple shards for one collection on the same Solr
server"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message