auto-valued fields

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

auto-valued fields

Erik Hatcher
I've been thinking that Solr could benefit from "auto-valued" fields,  
such as a datestamp.  This would be a field defined in the schema,  
but its value comes from the Solr server itself rather than the  
client POSTing documents.  The client wouldn't post such a value at  
all (it'd be an error if it did, perhaps, or it could override the  
automatic value?).

Does this make sense as a feature request to the Solr server?

I could envision there being some other auto-valued fields computed  
on the server perhaps... like IP address of the request, username  
(when security eventually gets added), and so on.

Thoughts?
        Erik

Reply | Threaded
Open this post in threaded view
|

Re: auto-valued fields

Yonik Seeley
On 5/4/06, Erik Hatcher <[hidden email]> wrote:
> I've been thinking that Solr could benefit from "auto-valued" fields,
> such as a datestamp.  This would be a field defined in the schema,
> but its value comes from the Solr server itself rather than the
> client POSTing documents.  The client wouldn't post such a value at
> all (it'd be an error if it did, perhaps, or it could override the
> automatic value?).
>
> Does this make sense as a feature request to the Solr server?

Definitely... I had previously thought about auto-incrementing fields
(for documents without a natural uniqueKey)... but to be useful, that
id may need to be returned in the response.

A server-set date field both makes sense *and* is easy to implement.

-Yonik
Reply | Threaded
Open this post in threaded view
|

Re: auto-valued fields

kkrugler
>On 5/4/06, Erik Hatcher <[hidden email]> wrote:
>>I've been thinking that Solr could benefit from "auto-valued" fields,
>>such as a datestamp.  This would be a field defined in the schema,
>>but its value comes from the Solr server itself rather than the
>>client POSTing documents.  The client wouldn't post such a value at
>>all (it'd be an error if it did, perhaps, or it could override the
>>automatic value?).
>>
>>Does this make sense as a feature request to the Solr server?
>
>Definitely... I had previously thought about auto-incrementing fields
>(for documents without a natural uniqueKey)... but to be useful, that
>id may need to be returned in the response.
>
>A server-set date field both makes sense *and* is easy to implement.

And then there's the auto-generated unique ID value that I'd like :)

-- Ken
--
Ken Krugler
Krugle, Inc.
+1 530-210-6378
"Find Code, Find Answers"
Reply | Threaded
Open this post in threaded view
|

Re: auto-valued fields

Yonik Seeley
In reply to this post by Yonik Seeley
On 5/4/06, Ken Krugler <[hidden email]> wrote:

> >On 5/4/06, Erik Hatcher <[hidden email]> wrote:
> >>I've been thinking that Solr could benefit from "auto-valued" fields,
> >>such as a datestamp.  This would be a field defined in the schema,
> >>but its value comes from the Solr server itself rather than the
> >>client POSTing documents.  The client wouldn't post such a value at
> >>all (it'd be an error if it did, perhaps, or it could override the
> >>automatic value?).
> >>
> >>Does this make sense as a feature request to the Solr server?
> >
> >Definitely... I had previously thought about auto-incrementing fields
> >(for documents without a natural uniqueKey)... but to be useful, that
> >id may need to be returned in the response.
> >
> >A server-set date field both makes sense *and* is easy to implement.
>
> And then there's the auto-generated unique ID value that I'd like :)

Yeah... that's what what I meant by auto-incrementing fields.
For that to be useful, the generated id would need to be returnd in
the response to the add, right?

-Yonik
Reply | Threaded
Open this post in threaded view
|

Re: auto-valued fields

kkrugler
>On 5/4/06, Ken Krugler <[hidden email]> wrote:
>>  >On 5/4/06, Erik Hatcher <[hidden email]> wrote:
>>>>I've been thinking that Solr could benefit from "auto-valued" fields,
>>>>such as a datestamp.  This would be a field defined in the schema,
>>>>but its value comes from the Solr server itself rather than the
>>>>client POSTing documents.  The client wouldn't post such a value at
>>>>all (it'd be an error if it did, perhaps, or it could override the
>>>>automatic value?).
>>>>
>>>>Does this make sense as a feature request to the Solr server?
>>>
>>>Definitely... I had previously thought about auto-incrementing fields
>>>(for documents without a natural uniqueKey)... but to be useful, that
>>>id may need to be returned in the response.
>>>
>>>A server-set date field both makes sense *and* is easy to implement.
>>
>>And then there's the auto-generated unique ID value that I'd like :)
>
>Yeah... that's what what I meant by auto-incrementing fields.

What I use is a PRNG, to mix up the IDs, but I guess that's a form of
an auto-incrementing field.

>For that to be useful, the generated id would need to be returnd in
>the response to the add, right?

Yes.

-- Ken
--
Ken Krugler
Krugle, Inc.
+1 530-210-6378
"Find Code, Find Answers"
Reply | Threaded
Open this post in threaded view
|

Re: auto-valued fields

Yonik Seeley
In reply to this post by Yonik Seeley
On 5/4/06, Ken Krugler <[hidden email]> wrote:
> What I use is a PRNG, to mix up the IDs, but I guess that's a form of
> an auto-incrementing field.

One advantage an incrementing field would have for auto-generated ids
is a uniqueness guarantee w/o having to search in the lucene index.

You could find the max in the index once, and then keep incrementing
the value for each new document added.

-Yonik
Reply | Threaded
Open this post in threaded view
|

Re: auto-valued fields

Chris Hostetter-3
In reply to this post by Erik Hatcher

: I've been thinking that Solr could benefit from "auto-valued" fields,
: such as a datestamp.  This would be a field defined in the schema,
: but its value comes from the Solr server itself rather than the
: client POSTing documents.  The client wouldn't post such a value at
: all (it'd be an error if it did, perhaps, or it could override the
: automatic value?).

great minds think alike ... i added this to the long term task list about
a month ago...


support for an an optional "timestamp" style field in schemas which
allways want every doc to include the datetime the document was added to
the index. This might be a special case (like the uniqueKey field) or it
could involve more general "default" support for fields and fieldtypes
(ie: <field> and <fieldtype> declarations could include a default="..."
attribute that gets put into any document that doesn't already have a
value for that field, with the underlying FieldType parsing the text each
time it's used, so that the DateField class can convert default="now" to
the current time.



-Hoss

Reply | Threaded
Open this post in threaded view
|

Re: auto-valued fields

Erik Hatcher
Well, I guess that just goes to show that I ought to catch up on all  
the great notes and TOOD items that all of you fantastic Solr  
creators have made so I don't go reinventing the wheels.  Thanks Hoss!

        Erik

On May 4, 2006, at 5:20 PM, Chris Hostetter wrote:

>
> : I've been thinking that Solr could benefit from "auto-valued"  
> fields,
> : such as a datestamp.  This would be a field defined in the schema,
> : but its value comes from the Solr server itself rather than the
> : client POSTing documents.  The client wouldn't post such a value at
> : all (it'd be an error if it did, perhaps, or it could override the
> : automatic value?).
>
> great minds think alike ... i added this to the long term task list  
> about
> a month ago...
>
>
> support for an an optional "timestamp" style field in schemas which
> allways want every doc to include the datetime the document was  
> added to
> the index. This might be a special case (like the uniqueKey field)  
> or it
> could involve more general "default" support for fields and fieldtypes
> (ie: <field> and <fieldtype> declarations could include a  
> default="..."
> attribute that gets put into any document that doesn't already have a
> value for that field, with the underlying FieldType parsing the  
> text each
> time it's used, so that the DateField class can convert  
> default="now" to
> the current time.
>
>
>
> -Hoss

Reply | Threaded
Open this post in threaded view
|

Re: auto-valued fields

Chris Hostetter-3

: Well, I guess that just goes to show that I ought to catch up on all
: the great notes and TOOD items that all of you fantastic Solr
: creators have made so I don't go reinventing the wheels.  Thanks Hoss!

Don't get me wrong ... the wheel hasn't been invented yet, i don't even
think anyone is working on building a wheel -- the wheel has just been
theorized, and i've written some notes on how i think it might make sense
for a a wheel to work, if someone were to make one.




-Hoss