python client

[Ed Summers <eh...@pobox.com>]

If necessary I'd like to help out getting SOLR-216 [1] applied. The
python client that's currently in the trunk is horribly broken with
the server implementation. What remains to be done?

//Ed

[1] https://issues.apache.org/jira/browse/SOLR-216

Re: python client

[Mike Klaas <mi...@gmail.com>]

On 19-Sep-07, at 6:45 PM, Ed Summers wrote:

>
> So I agree there is no urgency on getting the new implementation
> checked in. I didn't realize yonik was going to update the existing
> client.

Neither did I.  He's full of surprises <g>.

-Mike

Re: python client

[Ed Summers <eh...@pobox.com>]

On 9/19/07, Mike Klaas <mi...@gmail.com> wrote:
> Is this still the case?  I'd be more inclined to check it in if 1. It
> didn't fail badly in the case of unicode and 2. Yonik hadn't fixed
> the current client but days ago.

I stand corrected the solr.py in svn now works, instead of barfing on
the new solr response format as it did a few days ago. I didn't check
if it handled unicode correctly...that can wait for a test suite :-)

--
r577338 | yonik | 2007-09-19 11:55:56 -0400 (Wed, 19 Sep 2007) | 1 line

make solr.py work with current server
--

So I agree there is no urgency on getting the new implementation
checked in. I didn't realize yonik was going to update the existing
client.

//Ed

Re: python client

[Mike Klaas <mi...@gmail.com>]

On 19-Sep-07, at 5:59 PM, Ed Summers wrote:

> On 9/19/07, Mike Klaas <mi...@gmail.com> wrote:
>> I'm not trying to be obtuse or anything, but could you elaborate on
>> what problems are caused by not having the file checked in?  After
>> all, it is a single file that can be just plopped into the client/
>> directory in your branch.
>
> The problem of writing unittests against code that isn't checked in
> and under revision control.

Hmm?  We typically check in code and tests at the same time.

I don't see a point developing test cases against the current checked- 
in solr.py; I'd envision:

1. check out trunk
2. download the new solr.py from JIRA
3. write unittest_solr.py (or whatever) that passes against the new  
solr.py
4. upload both to the JIRA issue, and so they can be checked in  
simultaneously.

> Actually the main problem is that what's
> in the ticket works (partially at least) and what is in svn doesn't
> work at all.

Is this still the case?  I'd be more inclined to check it in if 1. It  
didn't fail badly in the case of unicode and 2. Yonik hadn't fixed  
the current client but days ago.

thanks,
-Mike

Re: python client

[Ed Summers <eh...@pobox.com>]

On 9/19/07, Mike Klaas <mi...@gmail.com> wrote:
> I'm not trying to be obtuse or anything, but could you elaborate on
> what problems are caused by not having the file checked in?  After
> all, it is a single file that can be just plopped into the client/
> directory in your branch.

The problem of writing unittests against code that isn't checked in
and under revision control. Actually the main problem is that what's
in the ticket works (partially at least) and what is in svn doesn't
work at all.

//Ed

Re: python client

[Mike Klaas <mi...@gmail.com>]

On 19-Sep-07, at 11:33 AM, Ed Summers wrote:

> On 9/18/07, Mike Klaas <mi...@gmail.com> wrote:
>> I'm afraid it exists only in my imagination <g>
>
> IMHO it would be easier to work on said tests if the new client was in
> svn. The current python client checked into svn after all is totally
> broken, so committing what's in SOLR-216 [1] isn't going to cause any
> problems.

Actually Yonik make a few tweaks to fix the existing client in the  
interim.

I'm not trying to be obtuse or anything, but could you elaborate on  
what problems are caused by not having the file checked in?  After  
all, it is a single file that can be just plopped into the client/  
directory in your branch.

-Mike

Re: python client

[Ed Summers <eh...@pobox.com>]

On 9/18/07, Mike Klaas <mi...@gmail.com> wrote:
> I'm afraid it exists only in my imagination <g>

IMHO it would be easier to work on said tests if the new client was in
svn. The current python client checked into svn after all is totally
broken, so committing what's in SOLR-216 [1] isn't going to cause any
problems.

//Ed

[1] http://issues.apache.org/jira/browse/SOLR-216

Re: python client

[Mike Klaas <mi...@gmail.com>]

On 18-Sep-07, at 5:52 AM, Ed Summers wrote:

> On 9/17/07, Mike Klaas <mi...@gmail.com> wrote:
>> The most important thing that is lacking in my mind is a test suite.
>> It is great that you identified the unicode bug, but I would feel
>> much better if we could add that test case to unittest_solr.py and
>> verify that it doesn't recur in the future.  This would also catch
>> cases such as the client getting out of sync with the server.
>
> Absolutely, it needs a test suite. Were you referring to a
> unittest_solr.py that exists somewhere because I don't see it in the
> HEAD.

I'm afraid it exists only in my imagination <g>

-Mike

Re: python client

[Ed Summers <eh...@pobox.com>]

On 9/17/07, Mike Klaas <mi...@gmail.com> wrote:
> The most important thing that is lacking in my mind is a test suite.
> It is great that you identified the unicode bug, but I would feel
> much better if we could add that test case to unittest_solr.py and
> verify that it doesn't recur in the future.  This would also catch
> cases such as the client getting out of sync with the server.

Absolutely, it needs a test suite. Were you referring to a
unittest_solr.py that exists somewhere because I don't see it in the
HEAD.

//Ed

Re: python client

[Mike Klaas <mi...@gmail.com>]

On 16-Sep-07, at 5:43 PM, Ed Summers wrote:

> If necessary I'd like to help out getting SOLR-216 [1] applied. The
> python client that's currently in the trunk is horribly broken with
> the server implementation. What remains to be done?

It is on my list of things to review, though I'm working on a release  
deadline and haven't had much solr time.

The most important thing that is lacking in my mind is a test suite.   
It is great that you identified the unicode bug, but I would feel  
much better if we could add that test case to unittest_solr.py and  
verify that it doesn't recur in the future.  This would also catch  
cases such as the client getting out of sync with the server.

We could make it run against the example, frinstance.

-Mike