lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris A. Mattmann (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
Date Sat, 02 Jan 2010 06:19:54 GMT

    [ 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:18 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 that they read CHANGES.txt on any upgrades
or when they download the software.
     - 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_manua_l.
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 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 that they read CHANGES.txt on any upgrades
or when they download the software.
     - 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.


Mime
View raw message