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] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
Date Fri, 01 Jan 2010 17:33:54 GMT

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

Chris A. Mattmann commented on SOLR-1602:
-----------------------------------------

bq. I've got no strong opinions about moving the code (it would probably be easier to understand
if we changed it, but so many people use IDEs these days that i odn't know if it matters)
but if we do change it i'd prefer to go the deprecation route just out of consistency with
how we've dealt with the RequestHandlers and other utilities classes in the past - it's relatively
trivial to do, so there's very little down side - and while it's true someone w/ deprecation
warnings turned off probably won't notice - that's kind of the point behind doing deprecations,
you get them if you want, you ignore them if you don't - but things don't break.

Thanks for the comments Hoss. As for deprecations I'm totally for them, when the intention
is to limit the impact on classes and code that has infected a code base and the sheer impact
of changing all of the package imports etc. is so burndensome that you want to give someone
some time to do it, while still moving forward with the refactoring. I don't think that's
the case here. ResponseWriters aren't extensible as we've went back and forth all the time
about. I doubt many people have extended them. As far as writing their own, the code is likely
in their own package structure. So, I think in this case, despite being different than what
you guys have done before (which is a con), the pro is the change is so minute and likely
of little impact, we want the compiler to throw an error or 2, so the user can fix those one
or 2 and be set for all future releases.

{quote}additionally: the config file issue should not be downplayed. yes it would be a trivial
search/replace, but that's precisely the reason why it would aggravate users: because it would
be such a trivial change w/o any obvious benefit to the users.

(novice developers tend to be much more forgiving of eccentricities in the code base then
novice users are of upgrade incompatibilities)
{quote}

I'm just not seeing this. I'm a user of plenty of software and a developer of the same. If
someone told me I'd have to do a find/replace on a config file to take advantage of a new
version of software, and that find replace would have the impact of 7 or 8 lines which I probably
haven't touched in the config file anyways I really wouldn't care (in other words the benefits
far outweigh the negatives). Though this is a generalization, I'd say on average, customers
for software I've developed over the last 10 years really haven't either.

If it makes you feel better I could strip out and upload a small patch that only changes the
sorlconfig.xml file part of this issue, and then in CHANGES.txt we could reference this issue
and tell the users, OK here's a quick way to upgrade an existing deployment:

patch -p0 < curl "https://issues.apache.org/jira/secure/attachment/12426188/SOLR-1602.configonly.patch.txt"

or something like that?

Oh, also I opened up a vote thread for this. If you get a chance could you vote on it? Thanks
a lot Hoss.

> 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