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 17:25:54 GMT

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

Chris A. Mattmann edited comment on SOLR-1602 at 1/2/10 5:24 PM:
-----------------------------------------------------------------

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.Mattmann@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? In other words, why wait until runtime to catch
something that could have been caught apriori?

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





      was (Author: chrismattmann):
    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.Mattmann@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.


Mime
View raw message