[
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795871#action_12795871
]
Chris A. Mattmann commented on SOLR-1602:
-----------------------------------------
Hi Erik,
I'm sorry that you feel that way. I had one committer (Ryan) who voted on the
related thread I posted on this (
http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200912.mbox/%3cc760cb08.8b0a%25chris.a.mattm...@jpl.nasa.gov%3e
) and agreed with the issue as I've proposed even (with no deprecations). In
terms of speaking for your user community that's a pretty lofty statement
assuming that the view of 2 committers is that of your user community. This
hasn't been my Apache experience, nor my experience developing software in
general. BTW, besides being a developer, I'm also one of SOLR's _users_ as well
(as I'm sure you are too), so we're really wearing two hats here. I may be a
different type of user than the one you're targeting, but I'm a user
nonetheless and that should speak for something.
As for the Lucene index example, in terms of going to extreme, that's an
extreme example, right? We're not talking about a data file format here. We're
talking about a package move of classes that are really in the wrong package,
of which there are about < 10 of those classes in use right now (and by in use,
we're really talking about configuration because there's not that many people
that are compiling against them I would venture to guess, and if they are, I
stand firm it's better to be verbose in those situations). That's a big
difference in terms of indexes that can grow big, and that need to be long
lived and maintained than a solrconfig.xml file.
As far as a log message in the deprecated classes, that's an interesting case.
I'm assuming that this would catch users of SOLR that upgraded to 1.5 but that
didn't upgrade their solrconfig.xml, right (assuming that class deprecations go
in)? The only problem I see with that is that Joe user isn't always savvy
enough to go into a log file and if he is, then he's likely already savvy
enough to have read CHANGES.txt, right?
Like I said above, we could provide a script along with this patch (attached to
this issue) that users are required to run to upgrade their solrconfig.xml
files when upgrading to 1.5. This is pretty much what a lot of other Apache
projects, e.g., Hadoop, HBase do, in the form of telling users that they need
to run DFS upgrade on any Hadoop upgrade as a matter of principle, see:
http://hadoop.apache.org/common/docs/r0.17.2/hdfs_user_guide.html#Upgrade+and+Rollback.
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.
