From rubywilliam16@example.org Sun Sep 28 20:06:11 2008
Return-Path: <rubywilliam16@example.org>
Delivered-To: william16@example.org
Received: (qmail 33054 invoked from network); 28 Sep 2008 20:06:11 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 28 Sep 2008 20:06:11 -0000
Received: (qmail 60591 invoked by uid 500); 28 Sep 2008 20:06:09 -0000
Delivered-To: william16@example.org
Received: (qmail 60577 invoked by uid 500); 28 Sep 2008 20:06:09 -0000
Mailing-List: contact william16@example.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:william16@example.org>
List-Unsubscribe: <mailto:william16@example.org>
List-Post: <mailto:william16@example.org>
List-Id: <ruby-dev.lucene.apache.org>
Reply-To: william16@example.org
Delivered-To: mailing list william16@example.org
Received: (qmail 60566 invoked by uid 99); 28 Sep 2008 20:06:09 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Sep 2008 13:06:09 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of william16@example.org designates 83.161.120.155 as permitted sender)
Received: from [83.161.120.155] (HELO mu-out-0910.google.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Sep 2008 20:05:09 +0000
Received: by mu-out-0910.google.com with SMTP id i10so1083784mue.5
        for <william16@example.org>; Sun, 28 Sep 2008 13:05:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:mime-version:content-type;
        bh=+DwTRtyTMG55SSb42JOLifa11dPF71hrG6KvjUXUKZI=;
        b=EX5YZiTlZD04m99ZUA44nLZusmkvcbcKB8aNwzK47EbeEtet6W9SnWXpZves82l1xh
         Vbe6ilcQT6NJgiMqOheuEfoSaGsGxXc03DIOHUGw0LD4dWngQSJVs79yS1eQJgCKzAES
         ic23KoMmXWjFH8QI9MWQUY6LS8ssgjx6yaYWs=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:mime-version:content-type;
        b=aTDzdBbg1JMZLz+/axj8kScrS9BLy108gtuft1+RxftKYHbE7YwI5kTiJrAWmIia/d
         IjGiQSb2Joiy82ggnbar45oXS474ulAI8FsjPQmSTkAeV9zPTOioz4BECgDTH6NnnAjs
         DQeNEaXyiE6gFna6w2R6f5e1KLzaaZMkwJkqA=
Received: by 83.161.120.155 with SMTP id k15mr3075460muq.84.1222632325190;
        Sun, 28 Sep 2008 13:05:25 -0700 (PDT)
Received: by 83.161.120.155 with HTTP; Sun, 28 Sep 2008 13:05:25 -0700 (PDT)
Message-ID: <william16@example.org>
Date: Sun, 28 Sep 2008 16:05:25 -0400
From: "Matt Mitchell" <william16@example.org>
To: william16@example.org
Subject: Ideas for simplifying solr-ruby and making it better
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_11752_14721099.1222632325163"
X-Virus-Checked: Checked by ClamAV on apache.org

------=_Part_11752_14721099.1222632325163
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I'm trying gather some ideas for how solr-ruby's code can be simplified and
better. For example, a lot of the classes are just extending a base class as
a placeholder, and not really doing anything. Some of them extend a base
class and set one option; the request and response modules have a lot of
this going on. Another thing I'm thinking could be cleaned up, simplified or
even made dynamic is the field mapping; and it'd be nice to permit
arbitrary/un-mapped params to be passed in too. Some of the code doesn't
seem all that rubyish, and my feeling is that there are lots of places where
things could be made simpler.

Do any of you have ideas or things that you've disliked about solr-ruby? If
so, please say so! I've got all kinds of ideas I'd like to implement and
crank out, but for now I want to see what other people are thinking.

Matt

------=_Part_11752_14721099.1222632325163--

From rubywilliam16@example.org Sun Sep 28 22:23:34 2008
Return-Path: <rubywilliam16@example.org>
Delivered-To: william16@example.org
Received: (qmail 3742 invoked from network); 28 Sep 2008 22:23:34 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 28 Sep 2008 22:23:34 -0000
Received: (qmail 8845 invoked by uid 500); 28 Sep 2008 22:23:32 -0000
Delivered-To: william16@example.org
Received: (qmail 8834 invoked by uid 500); 28 Sep 2008 22:23:32 -0000
Mailing-List: contact william16@example.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:william16@example.org>
List-Unsubscribe: <mailto:william16@example.org>
List-Post: <mailto:william16@example.org>
List-Id: <ruby-dev.lucene.apache.org>
Reply-To: william16@example.org
Delivered-To: mailing list william16@example.org
Received: (qmail 8823 invoked by uid 99); 28 Sep 2008 22:23:32 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Sep 2008 15:23:32 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of william16@example.org designates 83.161.120.155 as permitted sender)
Received: from [83.161.120.155] (HELO mail.asahi-net.or.jp) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Sep 2008 22:22:31 +0000
Received: from [83.161.120.155] (w244069.ppp.asahi-net.or.jp [83.161.120.155])
	by mail.asahi-net.or.jp (Postfix) with ESMTP id ED4855EC83
	for <william16@example.org>; Mon, 29 Sep 2008 07:23:04 +0900 (JST)
Message-ID: <william16@example.org>
Date: Mon, 29 Sep 2008 07:22:57 +0900
From: Koji Sekiguchi <william16@example.org>
User-Agent: Thunderbird 83.161.120.155 (Windows/20080914)
MIME-Version: 1.0
To: william16@example.org
Subject: Re: Ideas for simplifying solr-ruby and making it better
References: <william16@example.org>
In-Reply-To: <william16@example.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Matt,

 > Do any of you have ideas or things that you've disliked about 
solr-ruby? If
 > so, please say so! I've got all kinds of ideas I'd like to implement and
 > crank out, but for now I want to see what other people are thinking.

I don't have a concrete idea of making it better, but I agree with you.
Do you have the idea? let's discuss it to be things more rubyish.

see also:
http://wiki.apache.org/solr/solr-ruby/BrainStorming

Koji


From rubywilliam16@example.org Mon Sep 29 13:38:02 2008
Return-Path: <rubywilliam16@example.org>
Delivered-To: william16@example.org
Received: (qmail 31029 invoked from network); 29 Sep 2008 13:38:02 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 29 Sep 2008 13:38:02 -0000
Received: (qmail 92819 invoked by uid 500); 29 Sep 2008 13:38:00 -0000
Delivered-To: william16@example.org
Received: (qmail 92804 invoked by uid 500); 29 Sep 2008 13:38:00 -0000
Mailing-List: contact william16@example.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:william16@example.org>
List-Unsubscribe: <mailto:william16@example.org>
List-Post: <mailto:william16@example.org>
List-Id: <ruby-dev.lucene.apache.org>
Reply-To: william16@example.org
Delivered-To: mailing list william16@example.org
Received: (qmail 92793 invoked by uid 99); 29 Sep 2008 13:38:00 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Sep 2008 06:38:00 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of william16@example.org designates 83.161.120.155 as permitted sender)
Received: from [83.161.120.155] (HELO ey-out-2122.google.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Sep 2008 13:36:59 +0000
Received: by ey-out-2122.google.com with SMTP id 6so531349eyi.53
        for <william16@example.org>; Mon, 29 Sep 2008 06:37:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:in-reply-to:mime-version:content-type:references;
        bh=OowUdsznkh8nBtnw6EFhPcmE677yn08+4e7FfiAWtwo=;
        b=o4WM9sZi/zahYeeDmnhjvl73bYwjcP8/Osjk9yKgg1tcdxcgrQOQcsyBMEUej88Ny9
         ITjP6WPQaBiKaUMgfDmEtIBYgURl3sgsKr2NstTt3iAwehgyRz+EjCpx4lAurctE+wuA
         DB8K5gf6FMzVZyaisRaRvMcxyWlAyl2db6rMo=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=Td8Ld+PMLFpyuH4/zE9h5LqK9monK2HjTcr1agG/AtDBGbpUiBkRpIYa6c8ekVeiZy
         HiFuMJzBblyBX7eGf3qfuUXadBerbxqSjxrAR/lqt7qyVf1kxWLBWiQNQAXZOoAvnX+W
         RxKfyAJv+ce2pBjkBENbF1iqkcSmzFX+Q+JjA=
Received: by 83.161.120.155 with SMTP id d5mr3751017muq.18.1222695434988;
        Mon, 29 Sep 2008 06:37:14 -0700 (PDT)
Received: by 83.161.120.155 with HTTP; Mon, 29 Sep 2008 06:37:14 -0700 (PDT)
Message-ID: <william16@example.org>
Date: Mon, 29 Sep 2008 09:37:14 -0400
From: "Matt Mitchell" <william16@example.org>
To: william16@example.org
Subject: Re: Ideas for simplifying solr-ruby and making it better
In-Reply-To: <william16@example.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_17834_7109433.1222695434986"
References: <william16@example.org>
	 <william16@example.org>
X-Virus-Checked: Checked by ClamAV on apache.org

------=_Part_17834_7109433.1222695434986
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hey Koji,

Yeah I've seen that page before. I'd love to see solr-ruby get to that
point!

I wonder if starting from the top down would be a good way to approach this
discussion. Like talking about the public API then talk about the code
underneath to support it, then refactoring etc.. So even before discussing
something request/response "placeholder" classes problem, I'll just express
some of the API things that I've always wanted and/or disliked ;)

* more rich and customizable document model:

  documents.each do {|doc| puts d.class==MyCustomDocClass}

* more rich and customizable facet model:

  response.facets.each do |facet|
    facet.field
    facet.hits
  end

* set document class type dynamically within result set before iterating:

  documents.assign_doc_class do |raw_doc|
    return Models888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4 if doc[:format_type]=='CD'
    return Models888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4StandardDoc
  end

  # this would be nice because sometimes we're iterating through a result
set with entirely different "types" of docs.

* document field method accessors
    doc.id (or at least doc[:id])
    # instead of
    doc['id']

* pagination aware result sets (documents and facets)

    documents.total_pages # etc.
    response.facets.has_next?

* ability to pass in arbitrary query fields directly to solr without
worrying about solr-ruby raising an error

* ability to bypass query field mapping completely while querying

* flatten :facets mapping so that:

  :facets=>{:fields=>[]}
  # becomes
  :facet_fields=>[]

* ability to query a custom :query_type and NOT having to create a custom
request/response class pair

Those things are pretty easy to implement. I'd imagine that if solr-ruby has
a solid API, and a simpler code base it'd also be pretty easy to implement
some of the ORM-like features included on the wiki page and even a more DSL
like approach to regular querying:

response = connectiion.search do |q|
  q.per_page 10
  q.query 'twain'
  q.filter_query :title, 'finn'
  q.facet_fields :title, :author
  q.query_field :title, 0.5
end

What do you think?

Matt

On Sun, Sep 28, 2008 at 6:22 PM, Koji Sekiguchi <william16@example.org> wrote:

> Matt,
>
> > Do any of you have ideas or things that you've disliked about solr-ruby?
> If
> > so, please say so! I've got all kinds of ideas I'd like to implement and
> > crank out, but for now I want to see what other people are thinking.
>
> I don't have a concrete idea of making it better, but I agree with you.
> Do you have the idea? let's discuss it to be things more rubyish.
>
> see also:
> http://wiki.apache.org/solr/solr-ruby/BrainStorming
>
> Koji
>
>

------=_Part_17834_7109433.1222695434986--

From rubywilliam16@example.org Mon Sep 29 16:43:49 2008
Return-Path: <rubywilliam16@example.org>
Delivered-To: william16@example.org
Received: (qmail 99741 invoked from network); 29 Sep 2008 16:43:49 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 29 Sep 2008 16:43:49 -0000
Received: (qmail 90499 invoked by uid 500); 29 Sep 2008 16:43:47 -0000
Delivered-To: william16@example.org
Received: (qmail 90417 invoked by uid 500); 29 Sep 2008 16:43:47 -0000
Mailing-List: contact william16@example.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:william16@example.org>
List-Unsubscribe: <mailto:william16@example.org>
List-Post: <mailto:william16@example.org>
List-Id: <ruby-dev.lucene.apache.org>
Reply-To: william16@example.org
Delivered-To: mailing list william16@example.org
Received: (qmail 90406 invoked by uid 99); 29 Sep 2008 16:43:47 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Sep 2008 09:43:47 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [83.161.120.155] (HELO cardero.textdrive.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Sep 2008 16:42:45 +0000
Received: from [83.161.120.155] (va-787-819-4430.dhcp.embarqhsd.net [83.161.120.155])
	by cardero.textdrive.com (Postfix) with ESMTP id D4869BD9B0
	for <william16@example.org>; Mon, 29 Sep 2008 16:42:48 +0000 (GMT)
Message-Id: <william16@example.org>
From: Jamie Orchard-Hays <william16@example.org>
To: william16@example.org
In-Reply-To: <william16@example.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Ideas for simplifying solr-ruby and making it better
Date: Mon, 29 Sep 2008 12:42:46 -0400
References: <william16@example.org> <william16@example.org> <william16@example.org>
X-Mailer: Apple Mail (2.929.2)
X-Virus-Checked: Checked by ClamAV on apache.org

Matt, you are the nexus of XTF and Solr. :-)


On Sep 29, 2008, at 9:37 AM, Matt Mitchell wrote:

> Hey Koji,
>
> Yeah I've seen that page before. I'd love to see solr-ruby get to that
> point!
>
> I wonder if starting from the top down would be a good way to  
> approach this
> discussion. Like talking about the public API then talk about the code
> underneath to support it, then refactoring etc.. So even before  
> discussing
> something request/response "placeholder" classes problem, I'll just  
> express
> some of the API things that I've always wanted and/or disliked ;)
>
> * more rich and customizable document model:
>
>  documents.each do {|doc| puts d.class==MyCustomDocClass}
>
> * more rich and customizable facet model:
>
>  response.facets.each do |facet|
>    facet.field
>    facet.hits
>  end
>
> * set document class type dynamically within result set before  
> iterating:
>
>  documents.assign_doc_class do |raw_doc|
>    return Models888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4 if doc[:format_type]=='CD'
>    return Models888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4StandardDoc
>  end
>
>  # this would be nice because sometimes we're iterating through a  
> result
> set with entirely different "types" of docs.
>
> * document field method accessors
>    doc.id (or at least doc[:id])
>    # instead of
>    doc['id']
>
> * pagination aware result sets (documents and facets)
>
>    documents.total_pages # etc.
>    response.facets.has_next?
>
> * ability to pass in arbitrary query fields directly to solr without
> worrying about solr-ruby raising an error
>
> * ability to bypass query field mapping completely while querying
>
> * flatten :facets mapping so that:
>
>  :facets=>{:fields=>[]}
>  # becomes
>  :facet_fields=>[]
>
> * ability to query a custom :query_type and NOT having to create a  
> custom
> request/response class pair
>
> Those things are pretty easy to implement. I'd imagine that if solr- 
> ruby has
> a solid API, and a simpler code base it'd also be pretty easy to  
> implement
> some of the ORM-like features included on the wiki page and even a  
> more DSL
> like approach to regular querying:
>
> response = connectiion.search do |q|
>  q.per_page 10
>  q.query 'twain'
>  q.filter_query :title, 'finn'
>  q.facet_fields :title, :author
>  q.query_field :title, 0.5
> end
>
> What do you think?
>
> Matt
>
> On Sun, Sep 28, 2008 at 6:22 PM, Koji Sekiguchi <william16@example.org>  
> wrote:
>
>> Matt,
>>
>>> Do any of you have ideas or things that you've disliked about solr- 
>>> ruby?
>> If
>>> so, please say so! I've got all kinds of ideas I'd like to  
>>> implement and
>>> crank out, but for now I want to see what other people are thinking.
>>
>> I don't have a concrete idea of making it better, but I agree with  
>> you.
>> Do you have the idea? let's discuss it to be things more rubyish.
>>
>> see also:
>> http://wiki.apache.org/solr/solr-ruby/BrainStorming
>>
>> Koji
>>
>>


From rubywilliam16@example.org Mon Sep 29 17:22:55 2008
Return-Path: <rubywilliam16@example.org>
Delivered-To: william16@example.org
Received: (qmail 33195 invoked from network); 29 Sep 2008 17:22:55 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 29 Sep 2008 17:22:55 -0000
Received: (qmail 59595 invoked by uid 500); 29 Sep 2008 17:22:54 -0000
Delivered-To: william16@example.org
Received: (qmail 59516 invoked by uid 500); 29 Sep 2008 17:22:54 -0000
Mailing-List: contact william16@example.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:william16@example.org>
List-Unsubscribe: <mailto:william16@example.org>
List-Post: <mailto:william16@example.org>
List-Id: <ruby-dev.lucene.apache.org>
Reply-To: william16@example.org
Delivered-To: mailing list william16@example.org
Received: (qmail 59505 invoked by uid 99); 29 Sep 2008 17:22:54 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Sep 2008 10:22:54 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of william16@example.org designates 83.161.120.155 as permitted sender)
Received: from [83.161.120.155] (HELO mail.asahi-net.or.jp) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Sep 2008 17:21:52 +0000
Received: from [83.161.120.155] (w244069.ppp.asahi-net.or.jp [83.161.120.155])
	by mail.asahi-net.or.jp (Postfix) with ESMTP id F2FE35CAC6
	for <william16@example.org>; Tue, 30 Sep 2008 02:20:40 +0900 (JST)
Message-ID: <william16@example.org>
Date: Tue, 30 Sep 2008 02:20:32 +0900
From: Koji Sekiguchi <william16@example.org>
User-Agent: Thunderbird 83.161.120.155 (Windows/20080914)
MIME-Version: 1.0
To: william16@example.org
Subject: Re: Ideas for simplifying solr-ruby and making it better
References: <william16@example.org>	 <william16@example.org> <william16@example.org>
In-Reply-To: <william16@example.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

 > I wonder if starting from the top down would be a good way to 
approach this
 > discussion. Like talking about the public API then talk about the code
 > underneath to support it, then refactoring etc.. So even before 
discussing
 > something request/response "placeholder" classes problem, I'll just 
express
 > some of the API things that I've always wanted and/or disliked ;)

+1. Let's start from request/response "placeholder" classes.

 > * document field method accessors
 >     doc.id (or at least doc[:id])
 >     # instead of
 >     doc['id']

+1.

 > * ability to pass in arbitrary query fields directly to solr without
 > worrying about solr-ruby raising an error

Why do you need this ability?

Other than those above, I think you show good things up
to start our discussion and they are interesting.
I'd like to get comments/feedbacks from my associate (rubyist).

Cheers,

Koji


From rubywilliam16@example.org Tue Sep 30 01:41:14 2008
Return-Path: <rubywilliam16@example.org>
Delivered-To: william16@example.org
Received: (qmail 76919 invoked from network); 30 Sep 2008 01:41:14 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 30 Sep 2008 01:41:14 -0000
Received: (qmail 42662 invoked by uid 500); 30 Sep 2008 01:41:13 -0000
Delivered-To: william16@example.org
Received: (qmail 42651 invoked by uid 500); 30 Sep 2008 01:41:13 -0000
Mailing-List: contact william16@example.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:william16@example.org>
List-Unsubscribe: <mailto:william16@example.org>
List-Post: <mailto:william16@example.org>
List-Id: <ruby-dev.lucene.apache.org>
Reply-To: william16@example.org
Delivered-To: mailing list william16@example.org
Received: (qmail 42640 invoked by uid 99); 30 Sep 2008 01:41:13 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Sep 2008 18:41:13 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of william16@example.org designates 83.161.120.155 as permitted sender)
Received: from [83.161.120.155] (HELO nf-out-0910.google.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Sep 2008 01:40:09 +0000
Received: by nf-out-0910.google.com with SMTP id g16so688283nfd.15
        for <william16@example.org>; Mon, 29 Sep 2008 18:40:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:in-reply-to:mime-version:content-type:references;
        bh=Vyp6T0PH55ljPqwxScVw8Yo7XpGy/GaHYAfyjAV4uow=;
        b=NBU3OxwxFMMI41jKj5pWrWZvrSTH5S/tjJV/0uj5lpD0qHzADvNAaXEbgV5ubplJsO
         yLBhpooEVn2WZZ+yriKypx4y1HbvJ5Z90HYbmvcKLsnIQwWBmOoP4XM4PcOke9ebdooY
         z8NmI40+j41lmfs/I2BGGjzB/lxBjv7TjZf2w=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=aRTtGkFObq3nK5prwIQH3+F4f1qNy92ixagidyMSSquf6Qt9uL+Oinqzc1nbKp1xgV
         z7VMwj44BJs1ZGMOKxSWH2NJgVZUhzwcEKg7QMSvpuzAPYV0jzw6ZX3DzcCUMohM5RbX
         QvUV1CiN4UL5WF5g50SomTvUzLwsSpvuKB8Sg=
Received: by 83.161.120.155 with SMTP id a10mr4286103muh.109.1222738842085;
        Mon, 29 Sep 2008 18:40:42 -0700 (PDT)
Received: by 83.161.120.155 with HTTP; Mon, 29 Sep 2008 18:40:42 -0700 (PDT)
Message-ID: <william16@example.org>
Date: Mon, 29 Sep 2008 21:40:42 -0400
From: "Matt Mitchell" <william16@example.org>
To: william16@example.org
Subject: Re: Ideas for simplifying solr-ruby and making it better
In-Reply-To: <william16@example.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_24362_26752597.1222738842069"
References: <william16@example.org>
	 <william16@example.org>
	 <william16@example.org>
	 <william16@example.org>
X-Virus-Checked: Checked by ClamAV on apache.org

------=_Part_24362_26752597.1222738842069
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Koji. Thanks for the feedback!

In regard to the arbitrary query param issue. There are a few reasons why I
brought that up. The first is that there have been times where I wanted to
pass in something to Solr and solr-ruby hadn't yet supported it. Which means
there needs to be a continuous process of field mapping integration, at
least enough to keep up with the latest Solr param spec. Probably won't be
be a real problem, but it did happen to me once. Another issue is that,
sometimes I feel like the mapping gets in the way. Remembering all of the
Solr params is one thing, but then when you use solr-ruby you have to
remember a whole new set. Oh and the solr params are shorter :)

c.query(:q=>'battery operated', :fq=>'location:Chicago', :qf=>'title^0.5',
:fl=>'title, man, price')
# v.s.
c.query(:query=>'battery operated', :filter_queries=>['location:Chicago'],
:query_fields=>'title^0.5', :field_list=>['title', 'man', 'price'])

It'd be really nice to have the field mapping be optional, and even
better... plugable field mapping!

For the class placeholder issue... if we first start with the request
classes, we see there is a :response_format, :content_type, and a :handler.
The rest of the data is essentially query param stuff (field mapping). To
make it really simple, the :handler could dissapear, it'd just be set in the
method ('select' for a :query or :search, 'update' for a :delete etc.). The
:response_format could be set based on the :wt value. And the :content_type
could be a preset attribute in the connection instance. So, with that, you
just provide a method that accepts a hash of params.

The current request classes in solr-ruby (Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Request888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ismax etc.) really
look like query field mappers to me, that's what the bulk of the code is
doing it seems. So imagine for a querying... the connection class, a simple
query method, and then something like the current Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Request888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Standard
being thrown in as a plugable mapper?

Not to promote inheritence :) but if Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4onnection provided raw query ->
HTTP, you could do something like:

MyConnection < Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4onnection

  def query(params)
    super map(params) # the real query method accepts only raw solr
params...
  end

  protected
  def map(params)
    # convert my param structure to a raw solr query string...
  end

end

But there are better ways to do this in Ruby!

Matt

-- as an example, here is something I threw together a few weeks ago just to
get a feel for the minimal code needed for talking to solr. This is nothing
more than an experiment, hasn't been tested, and of course isn't a "real"
project!

lib:
http://github.com/mwmitchell/slite/tree/master/lib/slite.rb

example:
http://github.com/mwmitchell/slite/tree/master/README


>
> > * ability to pass in arbitrary query fields directly to solr without
> > worrying about solr-ruby raising an error
>
> Why do you need this ability?
>
> Other than those above, I think you show good things up
> to start our discussion and they are interesting.
> I'd like to get comments/feedbacks from my associate (rubyist).
>
> Cheers,
>
> Koji
>
>

------=_Part_24362_26752597.1222738842069--

From rubywilliam16@example.org Tue Sep 30 02:42:00 2008
Return-Path: <rubywilliam16@example.org>
Delivered-To: william16@example.org
Received: (qmail 31455 invoked from network); 30 Sep 2008 02:42:00 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 30 Sep 2008 02:42:00 -0000
Received: (qmail 95662 invoked by uid 500); 30 Sep 2008 02:41:59 -0000
Delivered-To: william16@example.org
Received: (qmail 95578 invoked by uid 500); 30 Sep 2008 02:41:58 -0000
Mailing-List: contact william16@example.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:william16@example.org>
List-Unsubscribe: <mailto:william16@example.org>
List-Post: <mailto:william16@example.org>
List-Id: <ruby-dev.lucene.apache.org>
Reply-To: william16@example.org
Delivered-To: mailing list william16@example.org
Received: (qmail 95566 invoked by uid 99); 30 Sep 2008 02:41:58 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Sep 2008 19:41:58 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [83.161.120.155] (HELO cardero.textdrive.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Sep 2008 02:40:54 +0000
Received: from [83.161.120.155] (va-787-819-4430.dhcp.embarqhsd.net [83.161.120.155])
	by cardero.textdrive.com (Postfix) with ESMTP id 21D91CBB48
	for <william16@example.org>; Tue, 30 Sep 2008 02:40:58 +0000 (GMT)
Message-Id: <william16@example.org>
From: Jamie Orchard-Hays <william16@example.org>
To: william16@example.org
In-Reply-To: <william16@example.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Ideas for simplifying solr-ruby and making it better
Date: Mon, 29 Sep 2008 22:40:56 -0400
References: <william16@example.org> <william16@example.org> <william16@example.org> <william16@example.org> <william16@example.org>
X-Mailer: Apple Mail (2.929.2)
X-Virus-Checked: Checked by ClamAV on apache.org

Matt, I think that that is a great idea. Really useful.


On Sep 29, 2008, at 9:40 PM, Matt Mitchell wrote:

> Hi Koji. Thanks for the feedback!
>
> In regard to the arbitrary query param issue. There are a few  
> reasons why I
> brought that up. The first is that there have been times where I  
> wanted to
> pass in something to Solr and solr-ruby hadn't yet supported it.  
> Which means
> there needs to be a continuous process of field mapping integration,  
> at
> least enough to keep up with the latest Solr param spec. Probably  
> won't be
> be a real problem, but it did happen to me once. Another issue is  
> that,
> sometimes I feel like the mapping gets in the way. Remembering all  
> of the
> Solr params is one thing, but then when you use solr-ruby you have to
> remember a whole new set. Oh and the solr params are shorter :)
>
> c.query(:q=>'battery  
> operated', :fq=>'location:Chicago', :qf=>'title^0.5',
> :fl=>'title, man, price')
> # v.s.
> c.query(:query=>'battery  
> operated', :filter_queries=>['location:Chicago'],
> :query_fields=>'title^0.5', :field_list=>['title', 'man', 'price'])
>
> It'd be really nice to have the field mapping be optional, and even
> better... plugable field mapping!
>
> For the class placeholder issue... if we first start with the request
> classes, we see there is a :response_format, :content_type, and  
> a :handler.
> The rest of the data is essentially query param stuff (field  
> mapping). To
> make it really simple, the :handler could dissapear, it'd just be  
> set in the
> method ('select' for a :query or :search, 'update' for a :delete  
> etc.). The
> :response_format could be set based on the :wt value. And  
> the :content_type
> could be a preset attribute in the connection instance. So, with  
> that, you
> just provide a method that accepts a hash of params.
>
> The current request classes in solr-ruby (Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Request888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ismax  
> etc.) really
> look like query field mappers to me, that's what the bulk of the  
> code is
> doing it seems. So imagine for a querying... the connection class, a  
> simple
> query method, and then something like the current  
> Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Request888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Standard
> being thrown in as a plugable mapper?
>
> Not to promote inheritence :) but if Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4onnection provided raw  
> query ->
> HTTP, you could do something like:
>
> MyConnection < Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4onnection
>
>  def query(params)
>    super map(params) # the real query method accepts only raw solr
> params...
>  end
>
>  protected
>  def map(params)
>    # convert my param structure to a raw solr query string...
>  end
>
> end
>
> But there are better ways to do this in Ruby!
>
> Matt
>
> -- as an example, here is something I threw together a few weeks ago  
> just to
> get a feel for the minimal code needed for talking to solr. This is  
> nothing
> more than an experiment, hasn't been tested, and of course isn't a  
> "real"
> project!
>
> lib:
> http://github.com/mwmitchell/slite/tree/master/lib/slite.rb
>
> example:
> http://github.com/mwmitchell/slite/tree/master/README
>
>
>>
>>> * ability to pass in arbitrary query fields directly to solr without
>>> worrying about solr-ruby raising an error
>>
>> Why do you need this ability?
>>
>> Other than those above, I think you show good things up
>> to start our discussion and they are interesting.
>> I'd like to get comments/feedbacks from my associate (rubyist).
>>
>> Cheers,
>>
>> Koji
>>
>>


From rubywilliam16@example.org Tue Sep 30 09:50:48 2008
Return-Path: <rubywilliam16@example.org>
Delivered-To: william16@example.org
Received: (qmail 62358 invoked from network); 30 Sep 2008 09:50:48 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 30 Sep 2008 09:50:48 -0000
Received: (qmail 50382 invoked by uid 500); 30 Sep 2008 09:50:46 -0000
Delivered-To: william16@example.org
Received: (qmail 50360 invoked by uid 500); 30 Sep 2008 09:50:46 -0000
Mailing-List: contact william16@example.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:william16@example.org>
List-Unsubscribe: <mailto:william16@example.org>
List-Post: <mailto:william16@example.org>
List-Id: <ruby-dev.lucene.apache.org>
Reply-To: william16@example.org
Delivered-To: mailing list william16@example.org
Received: (qmail 50349 invoked by uid 99); 30 Sep 2008 09:50:46 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Sep 2008 02:50:46 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [83.161.120.155] (HELO ehatchersolutions.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Sep 2008 09:49:41 +0000
Received: by ehatchersolutions.com (Postfix, from userid 504)
	id D038F30EFC16; Tue, 30 Sep 2008 03:49:35 -0600 (MDT)
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on javelina
X-Spam-Level: 
Received: from [83.161.120.155] (va-69-68-188-253.dyn.embarqhsd.net [83.161.120.155])
	by ehatchersolutions.com (Postfix) with ESMTP id 5631330EFC16
	for <william16@example.org>; Tue, 30 Sep 2008 03:49:34 -0600 (MDT)
Message-Id: <william16@example.org>
From: Erik Hatcher <william16@example.org>
To: william16@example.org
In-Reply-To: <william16@example.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: Ideas for simplifying solr-ruby and making it better
Date: Tue, 30 Sep 2008 05:49:33 -0400
References: <william16@example.org> <william16@example.org> <william16@example.org> <william16@example.org> <william16@example.org>
X-Mailer: Apple Mail (2.928.1)
X-Virus-Checked: Checked by ClamAV on apache.org
X-Old-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_DUL 
	autolearn=no version=3.1.1


On Sep 29, 2008, at 9:40 PM, Matt Mitchell wrote:
> In regard to the arbitrary query param issue. There are a few  
> reasons why I
> brought that up. The first is that there have been times where I  
> wanted to
> pass in something to Solr and solr-ruby hadn't yet supported it.  
> Which means
> there needs to be a continuous process of field mapping integration,  
> at
> least enough to keep up with the latest Solr param spec. Probably  
> won't be
> be a real problem, but it did happen to me once. Another issue is  
> that,
> sometimes I feel like the mapping gets in the way. Remembering all  
> of the
> Solr params is one thing, but then when you use solr-ruby you have to
> remember a whole new set. Oh and the solr params are shorter :)

Yeah, it was a bit over designed to have alias and be too clever with  
parameter mappings from Ruby to HTTP.  I'd like to strip away all the  
mappings and have solr-ruby in its most elementary API be able to  
simply pass through parameters and get the raw Ruby response data  
structure back.  Very quickly folks will want to build on top of that  
to make things cleaner, but that is fine.

> c.query(:q=>'battery  
> operated', :fq=>'location:Chicago', :qf=>'title^0.5',
> :fl=>'title, man, price')
> # v.s.
> c.query(:query=>'battery  
> operated', :filter_queries=>['location:Chicago'],
> :query_fields=>'title^0.5', :field_list=>['title', 'man', 'price'])
>
> It'd be really nice to have the field mapping be optional, and even
> better... plugable field mapping!

   +1

Note that the current Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Request888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Select is pretty close to what  
you're asking for here.

One thing I want to really handle cleanly is custom request handler  
mappings - making it trivial to request to any handler.  It's not too  
bad now, but the paired Request/Response class structure needs to go.

> The current request classes in solr-ruby (Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Request888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ismax  
> etc.) really
> look like query field mappers to me, that's what the bulk of the  
> code is
> doing it seems. So imagine for a querying... the connection class, a  
> simple
> query method, and then something like the current  
> Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Request888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Standard
> being thrown in as a plugable mapper?

+1

> Not to promote inheritence :) but if Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4onnection provided raw  
> query ->
> HTTP, you could do something like:
>
> MyConnection < Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4onnection
>
>  def query(params)
>    super map(params) # the real query method accepts only raw solr
> params...
>  end
>
>  protected
>  def map(params)
>    # convert my param structure to a raw solr query string...
>  end
>
> end
>
> But there are better ways to do this in Ruby!

Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4onnection does provide pretty raw operations to Solr.  Look at  
Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4onnection#post.  Pass in an object that has #handler, #to_s,  
and #content_type methods in and you're off and running.  The #to_s  
being the key to parameter mapping.

> -- as an example, here is something I threw together a few weeks ago  
> just to
> get a feel for the minimal code needed for talking to solr. This is  
> nothing
> more than an experiment, hasn't been tested, and of course isn't a  
> "real"
> project!
>
> lib:
> http://github.com/mwmitchell/slite/tree/master/lib/slite.rb
>
> example:
> http://github.com/mwmitchell/slite/tree/master/README

Cute stuff, Matt!

I think there are goodies to be mined from there for sure.

How about using #method_missing on Connection such that  
connection.whatever(:key => 'value') would call to the "whatever"  
request handler?  That'd be cool.

I'm not sure I agree with creating objects beyond the eval of the Ruby  
response though.  At least not in the core of solr-ruby.  Let's let  
the response from Solr itself be the only object a client really  
needs.  Conversion to other objects can occur a layer above the inner  
core of solr-ruby, such as acts_as_solr.

Keep in mind we have access to to change Solr's response format to  
suit solr-ruby's needs also.  And I can see some custom solr-ruby  
classes coming into play that Solr's Ruby response would emit.

	Erik


From rubywilliam16@example.org Tue Sep 30 10:10:53 2008
Return-Path: <rubywilliam16@example.org>
Delivered-To: william16@example.org
Received: (qmail 70806 invoked from network); 30 Sep 2008 10:10:53 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 30 Sep 2008 10:10:53 -0000
Received: (qmail 68127 invoked by uid 500); 30 Sep 2008 10:10:51 -0000
Delivered-To: william16@example.org
Received: (qmail 68107 invoked by uid 500); 30 Sep 2008 10:10:51 -0000
Mailing-List: contact william16@example.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:william16@example.org>
List-Unsubscribe: <mailto:william16@example.org>
List-Post: <mailto:william16@example.org>
List-Id: <ruby-dev.lucene.apache.org>
Reply-To: william16@example.org
Delivered-To: mailing list william16@example.org
Received: (qmail 68096 invoked by uid 99); 30 Sep 2008 10:10:51 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Sep 2008 03:10:51 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [83.161.120.155] (HELO ehatchersolutions.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Sep 2008 10:09:46 +0000
Received: by ehatchersolutions.com (Postfix, from userid 504)
	id 9B98230EFC17; Tue, 30 Sep 2008 04:09:35 -0600 (MDT)
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on javelina
X-Spam-Level: 
Received: from [83.161.120.155] (va-69-68-188-253.dyn.embarqhsd.net [83.161.120.155])
	by ehatchersolutions.com (Postfix) with ESMTP id 288F330EFC16
	for <william16@example.org>; Tue, 30 Sep 2008 04:09:29 -0600 (MDT)
Message-Id: <william16@example.org>
From: Erik Hatcher <william16@example.org>
To: william16@example.org
In-Reply-To: <william16@example.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: Ideas for simplifying solr-ruby and making it better
Date: Tue, 30 Sep 2008 06:09:28 -0400
References: <william16@example.org> <william16@example.org> <william16@example.org> <william16@example.org> <william16@example.org> <william16@example.org>
X-Mailer: Apple Mail (2.928.1)
X-Virus-Checked: Checked by ClamAV on apache.org
X-Old-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_DUL 
	autolearn=no version=3.1.1

One other big wish list item I have for solr-ruby beyond gutting it  
and simplifying it to the bare essentials, is to make it JRuby-aware.   
When running with JRuby, the SolrJ library will be used and will allow  
the use of SolrServer such that an EmbeddedSolrServer can be used.  I  
suspect we can make this all seamless somehow such that MRI works fine  
over HTTP, and JRuby gets the advantage of being able to work really  
nicely with embedded Solr.

	Erik


On Sep 30, 2008, at 5:49 AM, Erik Hatcher wrote:

>
> On Sep 29, 2008, at 9:40 PM, Matt Mitchell wrote:
>> In regard to the arbitrary query param issue. There are a few  
>> reasons why I
>> brought that up. The first is that there have been times where I  
>> wanted to
>> pass in something to Solr and solr-ruby hadn't yet supported it.  
>> Which means
>> there needs to be a continuous process of field mapping  
>> integration, at
>> least enough to keep up with the latest Solr param spec. Probably  
>> won't be
>> be a real problem, but it did happen to me once. Another issue is  
>> that,
>> sometimes I feel like the mapping gets in the way. Remembering all  
>> of the
>> Solr params is one thing, but then when you use solr-ruby you have to
>> remember a whole new set. Oh and the solr params are shorter :)
>
> Yeah, it was a bit over designed to have alias and be too clever  
> with parameter mappings from Ruby to HTTP.  I'd like to strip away  
> all the mappings and have solr-ruby in its most elementary API be  
> able to simply pass through parameters and get the raw Ruby response  
> data structure back.  Very quickly folks will want to build on top  
> of that to make things cleaner, but that is fine.
>
>> c.query(:q=>'battery  
>> operated', :fq=>'location:Chicago', :qf=>'title^0.5',
>> :fl=>'title, man, price')
>> # v.s.
>> c.query(:query=>'battery  
>> operated', :filter_queries=>['location:Chicago'],
>> :query_fields=>'title^0.5', :field_list=>['title', 'man', 'price'])
>>
>> It'd be really nice to have the field mapping be optional, and even
>> better... plugable field mapping!
>
>  +1
>
> Note that the current Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Request888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Select is pretty close to what  
> you're asking for here.
>
> One thing I want to really handle cleanly is custom request handler  
> mappings - making it trivial to request to any handler.  It's not  
> too bad now, but the paired Request/Response class structure needs  
> to go.
>
>> The current request classes in solr-ruby (Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Request888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ismax  
>> etc.) really
>> look like query field mappers to me, that's what the bulk of the  
>> code is
>> doing it seems. So imagine for a querying... the connection class,  
>> a simple
>> query method, and then something like the current  
>> Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Request888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Standard
>> being thrown in as a plugable mapper?
>
> +1
>
>> Not to promote inheritence :) but if Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4onnection provided raw  
>> query ->
>> HTTP, you could do something like:
>>
>> MyConnection < Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4onnection
>>
>> def query(params)
>>   super map(params) # the real query method accepts only raw solr
>> params...
>> end
>>
>> protected
>> def map(params)
>>   # convert my param structure to a raw solr query string...
>> end
>>
>> end
>>
>> But there are better ways to do this in Ruby!
>
> Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4onnection does provide pretty raw operations to Solr.  Look  
> at Solr888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4onnection#post.  Pass in an object that has #handler,  
> #to_s, and #content_type methods in and you're off and running.  The  
> #to_s being the key to parameter mapping.
>
>> -- as an example, here is something I threw together a few weeks  
>> ago just to
>> get a feel for the minimal code needed for talking to solr. This is  
>> nothing
>> more than an experiment, hasn't been tested, and of course isn't a  
>> "real"
>> project!
>>
>> lib:
>> http://github.com/mwmitchell/slite/tree/master/lib/slite.rb
>>
>> example:
>> http://github.com/mwmitchell/slite/tree/master/README
>
> Cute stuff, Matt!
>
> I think there are goodies to be mined from there for sure.
>
> How about using #method_missing on Connection such that  
> connection.whatever(:key => 'value') would call to the "whatever"  
> request handler?  That'd be cool.
>
> I'm not sure I agree with creating objects beyond the eval of the  
> Ruby response though.  At least not in the core of solr-ruby.  Let's  
> let the response from Solr itself be the only object a client really  
> needs.  Conversion to other objects can occur a layer above the  
> inner core of solr-ruby, such as acts_as_solr.
>
> Keep in mind we have access to to change Solr's response format to  
> suit solr-ruby's needs also.  And I can see some custom solr-ruby  
> classes coming into play that Solr's Ruby response would emit.
>
> 	Erik



{'source': 'Apache Software Foundation Public Mail Archives'}