You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Yonik Seeley <yo...@apache.org> on 2007/04/03 20:05:40 UTC
solr release planning for 1.2
While it doesn't particularly feel like a natural place to have a
release now, it has been 3.5 months since release 1.1, and that was
while we were still in the incubator.
More frequent releases allows users access to new features in a timely
manner without using a nightly build, and thus allows developers more
flexibility to change things between releases.
So what features / issues do people think we need to resolve before we
make a 1.2 release?
-Yonik
Re: solr release planning for 1.2
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 4/3/07, Yonik Seeley <yo...@apache.org> wrote:
> ...So what features / issues do people think we need to resolve before we
> make a 1.2 release?...
I agree that having a non-incubator release would be good, and as long
as it's stable I don't care too much about exactly what new features
are in it (also because I have little time for helping ATM).
-Bertrand
Re: solr release planning for 1.2
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Apr 3, 2007, at 3:06 PM, Ryan McKinley wrote:
> I want it all!!!
I'm with Ryan on that!
All of the issues Ryan mentioned would certainly make me ecstatic.
On that note, I've picked up SOLR-184 and will tinker with it in the
next day when I can, review and commit.
A released version of Solr with all of the error handling and
introspection/debugging capabilities would be perfect for solr-ruby
too. All those changes make some very amazing details available to
Solr clients.
I'll look at the other issues in the future if no one else picks them
up first.
Erik
> If you are thinking within the next week or two, I vote we focus on
> consistent response format and better error handling. I would suggest
> that rather then map /update to SolrUpdateServlet, it should use the
> new update handler framework - returning non 200 response for errors.
>
> I would also vote for something like SOLR-179, but i have not heard
> much feedback from others on that.
>
> If the timespan were longer, I would want to get in modifying/updating
> documents - but that still has a lot of design choices that we should
> all feel confident about.
>
> The other minor things I would like to see soon (but should not affect
> release) are SOLR-184 and SOLR-176
>
> ryan
>
>
> On 4/3/07, Yonik Seeley <yo...@apache.org> wrote:
>> While it doesn't particularly feel like a natural place to have a
>> release now, it has been 3.5 months since release 1.1, and that was
>> while we were still in the incubator.
>>
>> More frequent releases allows users access to new features in a
>> timely
>> manner without using a nightly build, and thus allows developers more
>> flexibility to change things between releases.
>>
>> So what features / issues do people think we need to resolve
>> before we
>> make a 1.2 release?
>>
>> -Yonik
>>
Re: solr release planning for 1.2
Posted by rubdabadub <ru...@gmail.com>.
Me toooo.. :-) Just too add my two cents :-) I would rather see a 3
mos release cycle then
mega big releases.. cos often times bugs i found were in customer site
and manging
customers wish... and most customer don't want to run nightly build on
production. This
is the case in enterprise segment. So I would love to see a regular
cycle of release from
solr. Off course this shouldn't create too much of a overhead so its
takes the fun out of
doing a release.
I would love to see SOLR-20 but as I remember this is not ready yet.
Cheers
On 4/3/07, Ryan McKinley <ry...@gmail.com> wrote:
> I want it all!!!
>
> If you are thinking within the next week or two, I vote we focus on
> consistent response format and better error handling. I would suggest
> that rather then map /update to SolrUpdateServlet, it should use the
> new update handler framework - returning non 200 response for errors.
>
> I would also vote for something like SOLR-179, but i have not heard
> much feedback from others on that.
>
> If the timespan were longer, I would want to get in modifying/updating
> documents - but that still has a lot of design choices that we should
> all feel confident about.
>
> The other minor things I would like to see soon (but should not affect
> release) are SOLR-184 and SOLR-176
>
> ryan
>
>
> On 4/3/07, Yonik Seeley <yo...@apache.org> wrote:
> > While it doesn't particularly feel like a natural place to have a
> > release now, it has been 3.5 months since release 1.1, and that was
> > while we were still in the incubator.
> >
> > More frequent releases allows users access to new features in a timely
> > manner without using a nightly build, and thus allows developers more
> > flexibility to change things between releases.
> >
> > So what features / issues do people think we need to resolve before we
> > make a 1.2 release?
> >
> > -Yonik
> >
>
Re: solr release planning for 1.2
Posted by Ryan McKinley <ry...@gmail.com>.
>
> : /update and /update/ could go to two different places. I'm not sure
> : why web.xml has update mapped to /update/*
>
> why would /update and /update/ be treated differently? dispatch filter
> will take them both and give them to XmlUpdateRequestHandler because it
> does prefix matching right?
>
nope, it is a map lookup, so it needs to be an exact match or it moves on.
http://localhost:8983/solr/update/csv 400 missing contentStream
http://localhost:8983/solr/update/csv/ 405 from the update servlet
I don't like prefix check because it leads you to things like:
/update/asgdasgda works just fine
We should strip trailing '/' from anything that gets registered and
when you pull stuff out of the registry, that would fix this problem.
I will file a JIRA issue for that.
>
> i don't think we should do this: 1) it changes things under the covers for
> existing users; 2) people are probably going to use one URL structure or
ok. alternativly,
perhaps we should add something to solrconfig that would achieve the
same thing, this way the example solrconfig.xml could get people used
to having an error code when errors occur.
I can't stress enough how important this is for new people and people
writing clients - it is so easy to have errors go unnoticed when they
have a 200 response.
> : All of these are useful to people getting started with solr and
> : helpful debugging tools. I've convinced a bunch of people to use solr
>
> I personally don't think we need to wait on any new functionality -- this
> release will already be fairly significant given what's already been
> commited (and that it's post incubation so all of hte release steps need
> to be re-sanity checked).
>
If its a question of *need*, i agree - I was answering what i would
*like* to see.
> : The one thing i can think of is that it would be nice to solidify the
> : "handler" package as the place that request handlers go. How do you
> : feel about deprecating o.a.s.request.StandardRequestHandler and moving
> : it to o.a.s.handler.StandardRequestHandler -- same for
> : DisMaxRequestHandler
>
> adding some package.html files clarifying what *should* be in each package
> definitely makes sense ... moving the existing request handlers is
> definitely a lower priority (especially since even if we move them, we'll
> need the placeholder subclasses for people currently subclassing them)
>
agreed, but if we hope to move them eventually, why not start the ball
rolling? If your fine with skipping the placeholder subclass in the
future and making people update their code, there is no need to do it
now. I just thought we should put the warning out now.
ryan
Re: solr release planning for 1.2
Posted by Chris Hostetter <ho...@fucit.org>.
: I'm suggesting we keep /update mapped to SolrUpdateServlet in web.xml, but map:
:
: <requestHandler name="/update" class="solr.XmlUpdateRequestHandler" >
:
: in solrconfig.xml. The only serious problem i see with that is that
yeah, that's the *example* solrconfig, which is why i'm on board with it
... it doesn't affect existing users in anyway unless they change their
config.
: /update and /update/ could go to two different places. I'm not sure
: why web.xml has update mapped to /update/*
why would /update and /update/ be treated differently? dispatch filter
will take them both and give them to XmlUpdateRequestHandler because it
does prefix matching right?
: I am not sure what we should do with the DispatchFilter handle-select parameter:
: <init-param>
: <param-name>handle-select</param-name>
: <param-value>true</param-value>
: </init-param>
:
: This would have the same error handling (and response codes) for
: /select?qt=xxx as it does for /path/mapped/in/config
i don't think we should do this: 1) it changes things under the covers for
existing users; 2) people are probably going to use one URL structure or
the other, the two don't really need to be perfectly consistent in their
behavior. The only reason i think we should eventually change this will
be down the road when we want to competely eliminte the old code paths
because we are confident very few people are using them because the
examplles have all had the new style.
which brings up a key point: we should change all the example urls in the
wiki/tutorial to use the new URL style.
: All of these are useful to people getting started with solr and
: helpful debugging tools. I've convinced a bunch of people to use solr
I personally don't think we need to wait on any new functionality -- this
release will already be fairly significant given what's already been
commited (and that it's post incubation so all of hte release steps need
to be re-sanity checked).
: The one thing i can think of is that it would be nice to solidify the
: "handler" package as the place that request handlers go. How do you
: feel about deprecating o.a.s.request.StandardRequestHandler and moving
: it to o.a.s.handler.StandardRequestHandler -- same for
: DisMaxRequestHandler
adding some package.html files clarifying what *should* be in each package
definitely makes sense ... moving the existing request handlers is
definitely a lower priority (especially since even if we move them, we'll
need the placeholder subclasses for people currently subclassing them)
-Hoss
Re: solr release planning for 1.2
Posted by Ryan McKinley <ry...@gmail.com>.
I put my (hopeful) todo list at:
http://wiki.apache.org/solr/Solr1%2e2
Re: solr release planning for 1.2
Posted by Yonik Seeley <yo...@apache.org>.
On 4/28/07, Ryan McKinley <ry...@gmail.com> wrote:
> If the configuration is in solrconfig.xml, we can set the example to use
> the dispatcher but still leave the option of the 'old' style servlet if
> that is desired. The only real difference between them is how errors
> are returned. The dispatcher calls req.sendError( code, msg ) while the
> servlet writes them out directly (causing them to be hidden by IE/FF)
I think only the body of the response changes since the HTTP error
codes were already being used for /select
Since the body of the response was never really specified, and it
wasn't in a parseable format, I think using sendError() could be
considered backward compatible.
-Yonik
Re: solr release planning for 1.2
Posted by Ryan McKinley <ry...@gmail.com>.
Yonik Seeley wrote:
> On 4/5/07, Ryan McKinley <ry...@gmail.com> wrote:
>> > I'm certainly on board with adding a requestHandler mapping for
>> "/update",
>> > but i'm not sure how i feel about changing it under the covers ...
>>
>> I'm suggesting we keep /update mapped to SolrUpdateServlet in web.xml,
>> but map:
>>
>> <requestHandler name="/update" class="solr.XmlUpdateRequestHandler" >
>
> +1
>
>> I am not sure what we should do with the DispatchFilter handle-select
>> parameter:
>> <init-param>
>> <param-name>handle-select</param-name>
>> <param-value>true</param-value>
>> </init-param>
>
> Why do we need this parameter? I thought that /select through
> DispatchFilter would be backward compatible with the servlet's current
> handling? If that's the case, just have dispatch handle it and be
> done with it.
>
Since writing this, I added SOLR-204 - this lets you configure if the
DispatchFilter will handle select in solrconfig.xml rather then web.xml
If the configuration is in solrconfig.xml, we can set the example to use
the dispatcher but still leave the option of the 'old' style servlet if
that is desired. The only real difference between them is how errors
are returned. The dispatcher calls req.sendError( code, msg ) while the
servlet writes them out directly (causing them to be hidden by IE/FF)
SOLR-204 removes the <init-param>
Re: solr release planning for 1.2
Posted by Yonik Seeley <yo...@apache.org>.
On 4/5/07, Ryan McKinley <ry...@gmail.com> wrote:
> > I'm certainly on board with adding a requestHandler mapping for "/update",
> > but i'm not sure how i feel about changing it under the covers ...
>
> I'm suggesting we keep /update mapped to SolrUpdateServlet in web.xml, but map:
>
> <requestHandler name="/update" class="solr.XmlUpdateRequestHandler" >
+1
> I am not sure what we should do with the DispatchFilter handle-select parameter:
> <init-param>
> <param-name>handle-select</param-name>
> <param-value>true</param-value>
> </init-param>
Why do we need this parameter? I thought that /select through
DispatchFilter would be backward compatible with the servlet's current
handling? If that's the case, just have dispatch handle it and be
done with it.
-Yonik
Re: solr release planning for 1.2
Posted by Ryan McKinley <ry...@gmail.com>.
>
> I'm certainly on board with adding a requestHandler mapping for "/update",
> but i'm not sure how i feel about changing it under the covers ...
I'm suggesting we keep /update mapped to SolrUpdateServlet in web.xml, but map:
<requestHandler name="/update" class="solr.XmlUpdateRequestHandler" >
in solrconfig.xml. The only serious problem i see with that is that
/update and /update/ could go to two different places. I'm not sure
why web.xml has update mapped to /update/*
I am not sure what we should do with the DispatchFilter handle-select parameter:
<init-param>
<param-name>handle-select</param-name>
<param-value>true</param-value>
</init-param>
This would have the same error handling (and response codes) for
/select?qt=xxx as it does for /path/mapped/in/config
BUT if someone wanted to opt-out of that change, they would need to
edit web.xml. I think consistent error handling is worth it, but I'm
not sure if this would hurt anyone.
> also gives options for people should bugs be encountered in either code
> path)
yes
> really need many more new features -- the real question is are there any
> large concepts currently "in progress" that should be finished off?
The major 'in progress' work still needs attention, so i don't think
they are suitable for a near term release.
That said, the things I would like to see included are:
SOLR-162, SOLR-184, and SOLR-179
All of these are useful to people getting started with solr and
helpful debugging tools. I've convinced a bunch of people to use solr
and these additions make it much easier for someone to help debug
without access to the machine. It is much nicer to have people
running official releases then a patched up war I build.
>
> And of course: are there any new "API" type things (config syntax, param
> names, etc...) since the 1.1 release that we want to tweak?
>
The one thing i can think of is that it would be nice to solidify the
"handler" package as the place that request handlers go. How do you
feel about deprecating o.a.s.request.StandardRequestHandler and moving
it to o.a.s.handler.StandardRequestHandler -- same for
DisMaxRequestHandler
we can leave an deprecated extended class in o.a.s.request untill the
next release or two. something like:
http://svn.apache.org/repos/asf/lucene/solr/trunk/src/java/org/apache/solr/request/ContentStream.java
This way anyone extending Standard or Dismax don't need to refactor immediately.
ryan
Re: solr release planning for 1.2
Posted by Chris Hostetter <ho...@fucit.org>.
: If you are thinking within the next week or two, I vote we focus on
: consistent response format and better error handling. I would suggest
: that rather then map /update to SolrUpdateServlet, it should use the
: new update handler framework - returning non 200 response for errors.
I'm certainly on board with adding a requestHandler mapping for "/update",
but i'm not sure how i feel about changing it under the covers ... that
could have unexpected effects on people who rely on the current behavior
-- i'd rather have a few releases under our belt with the option to use
the new framework there, and enabled in the example config, but by
default people with old style configs get the old style behavior (this
also gives options for people should bugs be encountered in either code
path)
: > So what features / issues do people think we need to resolve before we
: > make a 1.2 release?
in general, i haven't been following the patch queue closely enough to
have an opinions on anything that needs to be delt with before a release
can go out ... a quick skim of CHANGES.txt seems to indicate that we dont'
really need many more new features -- the real question is are there any
large concepts currently "in progress" that should be finished off?
And of course: are there any new "API" type things (config syntax, param
names, etc...) since the 1.1 release that we want to tweak?
-Hoss
Re: solr release planning for 1.2
Posted by Ryan McKinley <ry...@gmail.com>.
I want it all!!!
If you are thinking within the next week or two, I vote we focus on
consistent response format and better error handling. I would suggest
that rather then map /update to SolrUpdateServlet, it should use the
new update handler framework - returning non 200 response for errors.
I would also vote for something like SOLR-179, but i have not heard
much feedback from others on that.
If the timespan were longer, I would want to get in modifying/updating
documents - but that still has a lot of design choices that we should
all feel confident about.
The other minor things I would like to see soon (but should not affect
release) are SOLR-184 and SOLR-176
ryan
On 4/3/07, Yonik Seeley <yo...@apache.org> wrote:
> While it doesn't particularly feel like a natural place to have a
> release now, it has been 3.5 months since release 1.1, and that was
> while we were still in the incubator.
>
> More frequent releases allows users access to new features in a timely
> manner without using a nightly build, and thus allows developers more
> flexibility to change things between releases.
>
> So what features / issues do people think we need to resolve before we
> make a 1.2 release?
>
> -Yonik
>