[
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796102#action_12796102
]
Chris A. Mattmann commented on SOLR-1602:
-----------------------------------------
Hi Hoss:
Comments below:
{quote}
in all of those cases, we tried to provide a simple method for users who
depended on the legacy behavior to restore it with a simple configure change
which was advertised in the upgrade instructions.
{quote}
This is precisely what I suggested doing.
{quote}
In every one of those situations (that i can remember) we still had a few users
who got confused/frustrated at the change in behavior.
{quote}
The change I'm proposing doesn't change behavior. It changes configuration. The
two are different.
{quote}
I'm not suggesting that we should always strive for 100% back compat in the
configs and the request params and that people should expect identical configs
to always work in every Solr release for hte next 74 years - but so far, the
only times we've (knowingly) broken existing configs it was when the goal was
to either improve the default behavior, or add additional functionality. I've
got no problem telling 40% of our existing users "you need to add foo=bar to
your config to have it keep working" if it means that the other 60% and every
other new users gets something good out of deal....
{quote}
"good" is a qualitative term. I consider strong system design and organization
something that SOLR should be good at. All of the other qualities or observable
aspects of the system (performance, efficiency, scalability, etc.) are also
important things -- however, not to this issue.
{quote}
....but i see no good reason to break things for a large percentage of our user
base when there is no value add to them in return ... having a (subjectively)
cleaner code base is not a justification for making an upgrade break unless
users edit their configs, or run a script.
{quote}
There is value added in better system structure, architecture and code
organization. There are plenty of books written about the benefits of this and
I won't bother to go into detail. Further, "upgrade break" is sort of a loaded
phrase. It's not a break. It's an upgrade. Break would imply something out of
the norm, and I don't see any formal SOLR upgrade process that the approach
proposed in this issue deviates from. You suggested yourself that the types of
"upgrade" notations that this issue proposes in are advertised in CHANGES.txt.
This issue is no different.
{quote}
If breaking things was the only way to fix some major bug, or add some cool
feature, or saved us 100 man hours of development then i would be completley on
board telling people "sorry, please change this one line."
{quote}
There are many phases to the software engineering lifecycle. Development is
just one of them. This issue addresses time/cost savings in understandability
of SOLR's code base. For the quantitative value, I'll omit guessing as to the
general savings and just point to you to some reading on what *bad* code
organization and system structure can cause in terms of cost when others try
and understand your code [1] [2] [3].
{quote}
but when keeping things working takes such little effort, it would be
completley irresponsible to ___ our users over like that - trivial ___ like
needing to make a nusance edit to a config file for no apparent reason is what
drives users away and leaves a bad enough taste in their mouth that they
actively trash talk a product/project as being "unstable"
{quote}
I'm both a software developer and a user of SOLR, and the consistent resistance
to any proposed refactoring is quite troubling. As Uri noted above, software
requires refactoring, SOLR is no different. And as I noted from a code
organization standpoint, placing classes named response in a package named
request is _not_ subjectively anything -- it's poor design and it needs to be
addressed. As for "no apparent reason" as I mentioned to Noble, end-users of a
system don't dictate its code-level organization/design.
I'm also of the opinion that there are many stakeholders of any distributed
software system, SOLR being no different. Patrick iterated them above, as did I
and as did Uri. There aren't just "users" of SOLR -- there are end-users,
system administrators, core developers, plugin writers, architects, managers,
etc.
Cheers,
Chris
[1] http://portal.acm.org/citation.cfm?id=592025
[2] http://portal.acm.org/citation.cfm?id=302691
[3] http://portal.acm.org/citation.cfm?id=50089
> Refactor SOLR package structure to include o.a.solr.response and move
> QueryResponseWriters in there
> ---------------------------------------------------------------------------------------------------
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
> Issue Type: Improvement
> Components: Response Writers
> Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
> Reporter: Chris A. Mattmann
> Assignee: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt,
> SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are
> curiously located in the o.a.solr.request package. Not only is this package
> getting big (30+ classes), a lot of them are misplaced. There should be a
> first-class o.a.solr.response package, and the response related classes
> should be given a home there. Patch forthcoming.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
