In solr/trunk, we could do this with a pseudo field/transformer: https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/response/transform/
In trunk, you can return a function value -- but i'm not sure what the syntax for the 'fieldvalue' function would be. To use other functions, you just put it in the list: &fl=name,id,ord(id) On Wed, Sep 7, 2011 at 9:01 AM, Erick Erickson <[email protected]> wrote: > I'm more throwing this out there for discussion rather than implementing > it. Frankly, I suspect there are better things to spend time on.... > > Erick > > On Wed, Sep 7, 2011 at 7:13 AM, Chris Male <[email protected]> wrote: >> Hi, >> You can use the FieldCache to pull the single value of a field for a given >> document ID. >> I'm unsure about whether what you're suggesting is a good idea, but it would >> need to be a custom extension to how fields are retrieved currently. >> IndexReader.document(int) visits fields which are stored and the separation >> between indexed and stored fields is going to grow stronger. >> Good luck with it though, I can sort of see where you're coming from. >> >> On Wed, Sep 7, 2011 at 10:57 PM, Erick Erickson <[email protected]> >> wrote: >>> >>> I'm wondering if there's any utility in returning the first term of an >>> un-stored but >>> indexed field. It wouldn't be much use in a field that broke the >>> input stream up, >>> but what about a "string" type? Or something with KeywordTokenizer? >>> >>> We could save some index storage space, maybe speed up things a bit. >>> >>> Especially in a "string" type, there's no difference between the indexed >>> term >>> and the stored term, so why use both? >>> >>> My original notion was to let users include an indexed-but-not-stored >>> field in the fl list, and leave up to them to use it wisely. When >>> specified, the behavior >>> would be "return the first term encountered in an >>> indexed-but-not-tokenized field with >>> no guarantees". But it also occurs to me that we could do this >>> automagically for >>> "string" types. >>> >>> I haven't thought this through much, for instance what about >>> specifying fl=*? And >>> this changes current programs, users who already (by mistake probably) >>> specify >>> unstored fields in to be returned would start seeing new data. I'm sure >>> there are other gremlins. Not to mention trying to explain it. >>> >>> And, in truth, this really feels like one of those >>> possible-but-not-worth-the-effort >>> ideas. But it was in my head when I woke up this morning and I thought I'd >>> toss >>> it out there. >>> >>> Erick >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> >> -- >> Chris Male | Software Developer | JTeam BV.| www.jteam.nl >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
