[jira] Issue Comment Edited: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there

["Chris A. Mattmann (JIRA)" <ji...@apache.org>]

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

Chris A. Mattmann edited comment on SOLR-1602 at 1/2/10 6:17 AM:
-----------------------------------------------------------------

Hi Erik,

Thanks for your feedback. My comments below:

bq. Your rationalization only makes sense for developers that are compiling things... consider the case where someone has enabled the Velocity response writer (since it isn't yet enabled by default) and then it gets moved. Their upgrade is going to break for no good reason.

I'm sorry but I guess I feel it's more important to be strict and informative, rather than loose and accommodating on these types of changes. Let's elucidate a real scenario.

1. I'm a SOLR 1.4 user. 
2. I'm using the Velocity Response Writer, which means, I've gone to the trouble of making a small edit my solrconfig.xml configuration, and added a queryResponseWriter by enabling it with a few lines of XML in my configuration. 
3. I decide I'm going to use SOLR 1.5. 
    (corollary) SOLR-1602 goes in as I've proposed, with no deprecations
4. I upgrade to SOLR 1.5.
     - user A is the type that doesn't bother reading CHANGES.txt. Ideally this isn't the user you want to design for, but you as a development team are willing to accommodate these types of users, even though it's _highly_ encouraged.
     - user B is the type that believes it makes sense to read CHANGES.txt first. (clap clap)
     - let's take the example of user A: in this case, the guy goes to run a query and ask for a response with wt=veolcity and some selected template. The query breaks, with a SOLR error, with an informative message to the likes of: response writer o.a.solr.request.VelocityResponseWriter doesn't exist. I'm annoyed, but I say, hmm why would this not work anymore. Let me take a look to see what response writers are present on the classpath with a jar tvf (if I'm not savvy enough to do this then we've got a whole other problem on our hands). Even if this approach doesn't pan out, I'd argue user A is still savvy enough at that point to, _read_the_instruction_manual. In doing so, he finds the answer to his question. It's reactive rather than proactive, but we still arrive at a solution with a small amount of acceptable effort. (BTW in this case, user A is annoyed for what he believes to be "no good reason", but I can tell you from experience in government, research/academia and industry, this happens all the time. As developers, and good designers there is a good reason [better organization for a small user A annoyance cost]).
     - let's take the example of user B. It's a trivial subcase of user A's scenario, to the point where the user reads CHANGES.txt, notes the information in there, and proactively updates a few lines of XML in his configuration file

So, anyways, I hope I've made my point and I don't really ever seem to get a lot of support on these types of issues, regardless. As a software architect and someone that teaches a graduate course in this stuff, I can tell you putting things titled ResponseWriter in a request package is not the way to go, regardless if SOLR has made 20 releases so far or 1 (software architecture recovery, static analysis, and a host of other issues are affected by this. Imagine in 10 years a company has a SOLR deployment long after SOLR ++ or some-other-search-service +++ 2.0 has come out. Someone has to come in and recover the architecture of a SOLR system so that they can understand how the changes they'd like to make to evolve the system will impact the so-called "load bearing walls". These types of issues, if caught early on, help reduce this effort and ultimately reduce cost.)

Cheers,
Chris




      was (Author: chrismattmann):
    Hi Erik,

Thanks for your feedback. My comments below:

bq. Your rationalization only makes sense for developers that are compiling things... consider the case where someone has enabled the Velocity response writer (since it isn't yet enabled by default) and then it gets moved. Their upgrade is going to break for no good reason.

I'm sorry but I guess I feel it's more important to be strict and informative, rather than loose and accommodating on these types of changes. Let's elucidate a real scenario.

1. I'm a SOLR 1.4 user. 
2. I'm using the Velocity Response Writer, which means, I've got to the trouble of making a small edit my solrconfig.xml configuration, and added a queryResponseWriter by enabling it with a few lines of XML in my configuration. 
3. I decide I'm going to use SOLR 1.5. 
    (corollary) SOLR-1602 goes in as I've proposed, with no deprecations
4. I upgrade to SOLR 1.5.
     - user A is the type that doesn't bother reading CHANGES.txt. Ideally this isn't the user you want to design for, but you as a development team are willing to accommodate these types of users, even though it's _highly_ encouraged.
     - user B is the type that believes it makes sense to read CHANGES.txt first. (clap clap)
     - let's take the example of user A: in this case, the guy goes to run a query and ask for a response with wt=veolcity and some selected template. The query breaks, with a SOLR error, with an informative message to the likes of: response writer o.a.solr.request.VelocityResponseWriter doesn't exist. I'm annoyed, but I say, hmm why would this not work anymore. Let me take a look to see what response writers are present on the classpath with a jar tvf (if I'm not savvy enough to do this then we've got a whole other problem on our hands). Even if this approach doesn't pan out, I'd argue user A is still savvy enough at that point to, _read_the_instruction_manual. In doing so, he finds the answer to his question. It's reactive rather than proactive, but we still arrive at a solution with a small amount of acceptable effort. (BTW in this case, user A is annoyed for what he believes to be "no good reason", but I can tell you from experience in government, research/academia and industry, this happens all the time. As developers, and good designers there is a good reason [better organization for a small user A annoyance cost]).
     - let's take the example of user B. It's a trivial subcase of user A's scenario, to the point where the user reads CHANGES.txt, notes the information in there, and proactively updates a few lines of XML in his configuration file

So, anyways, I hope I've made my point and I don't really ever seem to get a lot of support on these types of issues, regardless. As a software architect and someone that teaches a graduate course in this stuff, I can tell you putting things titled ResponseWriter in a request package is not the way to go, regardless if SOLR has made 20 releases so far or 1 (software architecture recovery, static analysis, and a host of other issues are affected by this. Imagine in 10 years a company has a SOLR deployment long after SOLR ++ or some-other-search-service +++ 2.0 has come out. Someone has to come in and recover the architecture of a SOLR system so that they can understand how the changes they'd like to make to evolve the system will impact the so-called "load bearing walls". These types of issues, if caught early on, help reduce this effort and ultimately reduce cost.)

Cheers,
Chris



  
> 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
>
>
> 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.