You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Yonik Seeley <yo...@lucidimagination.com> on 2010/10/17 18:33:46 UTC

Re: svn commit: r1023520 - /lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java

FYI, rather than spamming the list with backports, I'm going to start
batching my backports to the 3x branch.

All the svn:mergeinfo updates for even the smallest merge is a real
nightmare.  Merges to the 3x branch are practically unreadable since
the real update is lost in the noise.

-Yonik
http://www.lucidimagination.com


On Sun, Oct 17, 2010 at 12:28 PM,  <yo...@apache.org> wrote:
> Author: yonik
> Date: Sun Oct 17 16:28:37 2010
> New Revision: 1023520
>
> URL: http://svn.apache.org/viewvc?rev=1023520&view=rev
> Log:
> close the request we created
>
> Modified:
>    lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java
>
> Modified: lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java
> URL: http://svn.apache.org/viewvc/lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java?rev=1023520&r1=1023519&r2=1023520&view=diff
> ==============================================================================
> --- lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java (original)
> +++ lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java Sun Oct 17 16:28:37 2010
> @@ -23,6 +23,7 @@ import org.apache.solr.common.params.Sol
>  import org.apache.solr.common.util.NamedList;
>  import org.apache.solr.common.util.XML;
>  import org.apache.solr.core.SolrCore;
> +import org.apache.solr.request.LocalSolrQueryRequest;
>  import org.apache.solr.request.SolrQueryRequest;
>  import org.apache.solr.request.SolrQueryRequestBase;
>  import org.apache.solr.response.SolrQueryResponse;
> @@ -117,15 +118,13 @@ public class XmlUpdateRequestHandler ext
>    */
>   @Deprecated
>   public void doLegacyUpdate(Reader input, Writer output) {
> -    try {
> -      SolrCore core = SolrCore.getSolrCore();
> +    SolrCore core = SolrCore.getSolrCore();
> +    SolrQueryRequest req = new LocalSolrQueryRequest(core, new HashMap<String,String[]>());
>
> +    try {
>       // Old style requests do not choose a custom handler
>       UpdateRequestProcessorChain processorFactory = core.getUpdateProcessingChain(null);
>
> -      SolrParams params = new MapSolrParams(new HashMap<String, String>());
> -      SolrQueryRequestBase req = new SolrQueryRequestBase(core, params) {
> -      };
>       SolrQueryResponse rsp = new SolrQueryResponse(); // ignored
>       XMLStreamReader parser = inputFactory.createXMLStreamReader(input);
>       UpdateRequestProcessor processor = processorFactory.createProcessor(req, rsp);
> @@ -142,6 +141,9 @@ public class XmlUpdateRequestHandler ext
>         log.error("Error writing to output stream: " + ee);
>       }
>     }
> +    finally {
> +      req.close();
> +    }
>   }
>   //////////////////////// SolrInfoMBeans methods //////////////////////
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Re: svn commit: r1023520 - /lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java

Posted by Robert Muir <rc...@gmail.com>.
On Mon, Oct 18, 2010 at 11:46 PM, Mark Miller <ma...@gmail.com> wrote:

>
> Is it really worth doing the merges when we are not going to reintegrate?
>

yes, it tracks what has and has not been backported. as mentioned
before, most patches wouldnt apply again anyway.

you bring up the same thing as grant, but i dont understand what the
"easier" option is: redoing the work again?!

again, if you aren't going to use the version control methods, thats
your choice. but set the mergeprops properly so that the end result is
the same, and those of us using svn can track what has/hasn't been
backported.

and if you arent using merge/marking merged, i don't know how you keep
up with what has/hasn't been backported...!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Re: svn commit: r1023520 - /lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java

Posted by Mark Miller <ma...@gmail.com>.
On Sun, Oct 17, 2010 at 12:58 PM, Robert Muir <rc...@gmail.com> wrote:

> On Sun, Oct 17, 2010 at 12:33 PM, Yonik Seeley
> <yo...@lucidimagination.com> wrote:
> > FYI, rather than spamming the list with backports, I'm going to start
> > batching my backports to the 3x branch.
> >
> > All the svn:mergeinfo updates for even the smallest merge is a real
> > nightmare.  Merges to the 3x branch are practically unreadable since
> > the real update is lost in the noise.
>
> And its only going to get worse, I mean its pretty likely we might do
> more refactoring between Lucene/Solr, moving files around and
> requiring more mergeprops.
>
> If we don't do something to filter the diffs, I can easily see a
> single line merge being 20 emails soon.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Is it really worth doing the merges when we are not going to reintegrate?

-- 
- Mark

http://www.lucidimagination.com

Re: svn commit: r1023520 - /lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java

Posted by Robert Muir <rc...@gmail.com>.
On Sun, Oct 17, 2010 at 12:33 PM, Yonik Seeley
<yo...@lucidimagination.com> wrote:
> FYI, rather than spamming the list with backports, I'm going to start
> batching my backports to the 3x branch.
>
> All the svn:mergeinfo updates for even the smallest merge is a real
> nightmare.  Merges to the 3x branch are practically unreadable since
> the real update is lost in the noise.

And its only going to get worse, I mean its pretty likely we might do
more refactoring between Lucene/Solr, moving files around and
requiring more mergeprops.

If we don't do something to filter the diffs, I can easily see a
single line merge being 20 emails soon.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org