Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of erickerickson@gmail.com
 designates 209.85.214.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <trinity-91a11f48-06fc-4d82-88c8-0f5b0134bd43-1347044598305@3capp-webde-bs30>
References: 
 <trinity-32a2a27d-595e-4a98-9667-8cfec28e509f-1347039098976@3capp-webde-bs39>
	<CAEFAe-Hw3nw=qVcPEXgifDF7vTjZnA=Vcbio4kYmNQfeh_g-+w@mail.gmail.com>
	<trinity-91a11f48-06fc-4d82-88c8-0f5b0134bd43-1347044598305@3capp-webde-bs30>
Date: Sat, 8 Sep 2012 13:27:16 -0700
Message-ID: 
 <CAN4YXvdM4tMeYxx5px5cpRyypqegErd7QJmCiZ6=WNiSkKikQg@mail.gmail.com>
Subject: Re: Re: Schema model to store additional field metadata
From: Erick Erickson <erickerickson@gmail.com>
To: solr-user@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

You might be confusing indexing and storing. When you
specify index=3D"true" in your field definition, the input
is tokenized, transformed, etc and the results of this
(see the admin/analysis) page is what is searched.

But when you specify stored=3D"true", a literal, verbatim
copy of the text is put in a distinct file, and when you
return data (e.g. fl=3Dfield1, field2...) then the verbatim
copy is returned.

If you specify both index=3D"true" and stored=3D"true" both
things happen, but they're entirely separate operations
even though they're on the same field....

So, let's assume you want to provide links to the images.
Having a field (multiValued?) with index=3D"false" and stored=3D"true"
would allow you to store all the img urls in a single field.

All that said, now it's up to your application layer that
constructs the pages for presentation to the user to
"do the right thing" with the returned fields to allow
images (or whatever) to be displayed.

Best
Erick

On Fri, Sep 7, 2012 at 12:03 PM,  <sysrq@web.de> wrote:
>> Why would you store the actual images in SOLR?
>
> No, the images are files on the filesystem. Only the path to the image sh=
ould be stored in Solr.
>
>> And you are most likely looking at dynamic fields as the solution
>>
>> 1) Define *_Path, *_Size, *_Alt as a dynamic field with appropriate type=
s
>> 2) During indexing, write those properties as Image_1_Path,
>> Image_1_Size, Image_1_Alt or some such
>> 3) Make sure that whatever search algorithm you have looks at those or
>> do a copyField to aggregate them into AllImage_Alt, etc.
>
> I was also thinking of a solution with dynamic fields, but I am very new =
to Solr and I am not sure if it is a good solution to solve this modelling =
issue. For example I thought about introducing two multiValued dynamic fiel=
ds (image_src_*, image_alt_*) and store image data like file path on disc a=
nd alt-attribute like this:
>
> title:     An article about Foo and Bar
> content:   This is some text about Foo and Bar.
> published: 2012.09.07T19:23
> image_src_1: 2012/09/foo.png
> image_alt_1: Foo. Waiting for the bus.
> image_src_2: 2012/04/images/bar.png
> image_src_3: 2012/02/abc.png
> image_alt_3: Foo and Bar at the beach
>
> Of course a alt attribute for some images could be missing. I don't know =
if this is a good or better solution for this. It feels clumsy to me, like =
a workaround. But maybe this is the way to model this data, I don't know?