[
https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510487#comment-13510487
]
Per Steffensen edited comment on SOLR-4114 at 12/5/12 2:10 PM:
---------------------------------------------------------------
bq. I don't even think we need to argue about it really.
Well if that is your opinion you will have a problem working on big projects.
You should find a private project to work on in your basement. I think it is
worth arguing about. Maybe not on this issue/ticket, but in general in the
community on the dev mailing list. I am surrounded by professional testers in
my everyday work, and what I hear from them is more and more pulling towards
behavioural testing.
bq. Currently solr has a lot of integration tests, how is that working out?!
I dont know how it works out, but if you see a lot of problems, I wouldnt blame
the integration-test over unit-test strategy (is such a strategy exists). I
have a gut fealing about then main problem of Solr is that no one ever dare to
do refactoring - the code is a mess. And that you really do not "trust your
test-suite".
If you want to to be able to "trust you test-suite" enough to dare doing big
refactorings, integration/behavioural tests are by far the best. Typically when
you do major refactoring you do not change the system-behaviour seen from the
outside. You basically re-organize the code internally in order to be able to
keep adding features, fixing bugs etc. without getting too confused. Therefore
"integration/behavioural" tests do not have to be changed during a big
refactor, and the ensure that your refactoring did not ruin functionality "seen
from the outside" (is it IS basically all you care about). Unit-tests usually
have to be changed during a major refactoring, because a big refactor often
includes getting rid of existing "units", splitting up existing "units", adding
new "units" etc.
was (Author: steff1193):
bq. I don't even think we need to argue about it really.
Well if that is your opinion you will have a problem working on big projects.
You should find a private project to work on in you basement. I think it is
worth arguing about. Maybe not on this issue/ticket, but in general in the
community on the dev mailing list. I am surrounded by professional testers in
my everyday work, and what I hear from them is more and more pulling towards
behavioural testing.
bq. Currently solr has a lot of integration tests, how is that working out?!
I dont know how it works out, but if you see a lot of problems, I wouldnt blame
the integration-test over unit-test strategy (is such a strategy exists). I
have a gut fealing about then main problem of Solr is that no one ever dare to
do refactoring - the code is a mess. And that you really do not "trust your
test-suite".
If you want to to be able to "trust you test-suite" enough to dare doing big
refactorings, integration/behavioural tests are by far the best. Typically when
you do major refactoring you do not change the system-behaviour seen from the
outside. You basically re-organize the code internally in order to be able to
keep adding features, fixing bugs etc. without getting too confused. Therefore
"integration/behavioural" tests do not have to be changed during a big
refactor. Unit-tests usually do, because a big refactor often includes getting
rid of existing "units", splitting up existing "units", adding new "units" etc.
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
