You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by deniz <de...@gmail.com> on 2013/10/10 03:50:23 UTC

Field with default value and stored=false, will be reset back to the default value in case of updating other fields

hi all,

I have encountered some problems and post it on stackoverflow here:
http://stackoverflow.com/questions/19285251/solr-field-with-default-value-resets-itself-if-it-is-stored-false 

as you can see from the response, does it make sense to open a bug ticket
for this? because, although i can workaround this by setting everything back
to stored=true, it does not make sense to keep every field stored while i
dont need to return them in the search result.. or will anyone can make more
detailed explanations that this is expected and normal? 



-----
Zeki ama calismiyor... Calissa yapar...
--
View this message in context: http://lucene.472066.n3.nabble.com/Field-with-default-value-and-stored-false-will-be-reset-back-to-the-default-value-in-case-of-updatins-tp4094508.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Field with default value and stored=false, will be reset back to the default value in case of updating other fields

Posted by Jason Hellman <jh...@innoventsolutions.com>.
The best use case I see for atomic updates typically involves avoid transmission of large documents for small field updates.  If you are updating a "readCount" field of a PDF document that is 1MB in size you will avoid resending the 1MB PDF document's data in order to increment the "readCount" field.

If, instead, we're talking about 5K database records then there's plenty of argument to be made that the whole document should just be retransmitted and thus avoid the (potentially) unnecessary cost of storing all fields.

As in everything, we face compromises…the question is which one better suits your needs.

On Oct 10, 2013, at 5:07 AM, Erick Erickson <er...@gmail.com> wrote:

> bq: so what is the point of having atomic updates if
> i need to update everything?
> 
> _nobody_ claims this is ideal, it does solve a certain use-case.
> We'd all like like true partial-updates that didn't require
> stored fields.
> 
> The use-case here is that you don't have access to the
> system-of-record so you don't have a choice.
> 
> See the JIRA about "stacked segments" for update without
> storing fields work.
> 
> Best,
> Erick
> 
> On Thu, Oct 10, 2013 at 12:09 AM, Shawn Heisey <el...@elyograg.org> wrote:
>> On 10/9/2013 8:39 PM, deniz wrote:
>>> Billnbell wrote
>>>> You have to update the whole record including all fields...
>>> 
>>> so what is the point of having atomic updates if i need to update
>>> everything?
>> 
>> If you have any regular fields that are not stored, atomic updates will
>> not work -- unstored field data will be lost.  If you have copyField
>> destination fields that *are* stored, atomic updates will not work as
>> expected with those fields.  The wiki spells out the requirements:
>> 
>> http://wiki.apache.org/solr/Atomic_Updates#Caveats_and_Limitations
>> 
>> An atomic update is just a shortcut for "read all existing fields from
>> the original document, apply the atomic updates, and re-insert the
>> document, overwriting the original."
>> 
>> Thanks,
>> Shawn
>> 


Re: Field with default value and stored=false, will be reset back to the default value in case of updating other fields

Posted by Erick Erickson <er...@gmail.com>.
bq: so what is the point of having atomic updates if
i need to update everything?

_nobody_ claims this is ideal, it does solve a certain use-case.
We'd all like like true partial-updates that didn't require
stored fields.

The use-case here is that you don't have access to the
system-of-record so you don't have a choice.

See the JIRA about "stacked segments" for update without
storing fields work.

Best,
Erick

On Thu, Oct 10, 2013 at 12:09 AM, Shawn Heisey <el...@elyograg.org> wrote:
> On 10/9/2013 8:39 PM, deniz wrote:
>> Billnbell wrote
>>> You have to update the whole record including all fields...
>>
>> so what is the point of having atomic updates if i need to update
>> everything?
>
> If you have any regular fields that are not stored, atomic updates will
> not work -- unstored field data will be lost.  If you have copyField
> destination fields that *are* stored, atomic updates will not work as
> expected with those fields.  The wiki spells out the requirements:
>
> http://wiki.apache.org/solr/Atomic_Updates#Caveats_and_Limitations
>
> An atomic update is just a shortcut for "read all existing fields from
> the original document, apply the atomic updates, and re-insert the
> document, overwriting the original."
>
> Thanks,
> Shawn
>

Re: Field with default value and stored=false, will be reset back to the default value in case of updating other fields

Posted by Shawn Heisey <el...@elyograg.org>.
On 10/9/2013 8:39 PM, deniz wrote:
> Billnbell wrote
>> You have to update the whole record including all fields...
> 
> so what is the point of having atomic updates if i need to update
> everything? 

If you have any regular fields that are not stored, atomic updates will
not work -- unstored field data will be lost.  If you have copyField
destination fields that *are* stored, atomic updates will not work as
expected with those fields.  The wiki spells out the requirements:

http://wiki.apache.org/solr/Atomic_Updates#Caveats_and_Limitations

An atomic update is just a shortcut for "read all existing fields from
the original document, apply the atomic updates, and re-insert the
document, overwriting the original."

Thanks,
Shawn


Re: Field with default value and stored=false, will be reset back to the default value in case of updating other fields

Posted by deniz <de...@gmail.com>.
Billnbell wrote
> You have to update the whole record including all fields...

so what is the point of having atomic updates if i need to update
everything? 



-----
Zeki ama calismiyor... Calissa yapar...
--
View this message in context: http://lucene.472066.n3.nabble.com/Field-with-default-value-and-stored-false-will-be-reset-back-to-the-default-value-in-case-of-updatins-tp4094508p4094523.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Field with default value and stored=false, will be reset back to the default value in case of updating other fields

Posted by Bill Bell <bi...@gmail.com>.
You have to update the whole record including all fields...

Bill Bell
Sent from mobile


> On Oct 9, 2013, at 7:50 PM, deniz <de...@gmail.com> wrote:
> 
> hi all,
> 
> I have encountered some problems and post it on stackoverflow here:
> http://stackoverflow.com/questions/19285251/solr-field-with-default-value-resets-itself-if-it-is-stored-false 
> 
> as you can see from the response, does it make sense to open a bug ticket
> for this? because, although i can workaround this by setting everything back
> to stored=true, it does not make sense to keep every field stored while i
> dont need to return them in the search result.. or will anyone can make more
> detailed explanations that this is expected and normal? 
> 
> 
> 
> -----
> Zeki ama calismiyor... Calissa yapar...
> --
> View this message in context: http://lucene.472066.n3.nabble.com/Field-with-default-value-and-stored-false-will-be-reset-back-to-the-default-value-in-case-of-updatins-tp4094508.html
> Sent from the Solr - User mailing list archive at Nabble.com.