I had indexed a lot of data to solr.
One field named id is indexed as multivalued and string type (id:["123"]).
Now I want to change the field to int i.e (id:123).
Can I change the field type and how to effects the already existing data?
Yes, you can change the field type and also the multivalued as false by modifying the field from the schema.xml or managed-schema.
Once you modify the field type of field, you need to reindex the data.
I would suggest to create another collection using modified/different configset. This modified configset will have all the required changes to your schema.xml.
Once you upload this configSet, create a new collection and start indexing the data in your new collection.
Once indexing is complete. You can create an alias to the new collection and provide the alias name same as earlier collection, in order to avoid the downtime.
After the alias creation whatever searches will happen will be executed on the new collection.
I need to index documents on a SOLR server and update a specific field. I am using post jar on Windows for indexing the documents.
First question: is it possible to set the value of the required field directly from the post tool?
If not, text field is not stored but just indexed. As such, when I am doing the update of the field, the text field is losing all the content. I am updating the field using the http update (POST). The post parameters are: {"id":"D:\TESTNEWATTACH\AnexaNr.docx","PCC_TABLENAME":{"set":"PCC_CRM_ATTACH"}}
The main question is: how can I index a document and set a field belonging to that document without losing the document content search ability?
To update just a single field in a document, all fields has to be set as stored. If you don't have the fields set as stored, you'll lose the content when doing the update (as the process internally is retrieve document, update document, resubmit document).
The post tool supports giving arbitrary parameters to the update handler:
-params "=[&=...]" (values must be URL-encoded; these pass through to Solr update request)
.. which you can use with literal.fieldname=value to provide a value for the field(s) directly in the post request.
literal.<fieldname>
Populates a field with the name supplied with the specified value for each document. The data can be multivalued if the field is multivalued.
I need to populate a dropdown with all field names in a lucene index and need to show those values. I was able to do it successfully using
var luceneIndexReader IndexReader.Open("D:\path_to\index_directory", true);
var allAvailableFieldNames = luceneIndexReader.GetFieldNames(IndexReader.FieldOption.ALL);
Only problem is I need to include only 'Stored' fields in the drop down. This list includes all 'Indexed' and/or 'Stored' fields in it. Is there a way to query/search the indexes if a field has any 'stored' values and thereby filter out this list?
The problem is that every document in the index can have different fields containing stored fields. Since those are not storef as inverted index (they are stored per document) you can't retrieve them from the IndexReader. You need to retrieve one specific document, e.g. Document doc = indexReader.document(1); and call Fieldable fields[] = doc.getFields();. Then iterate over them and checking: field.isStored();.
Late at the party, but in the meanwhile you can just call FieldInfos# GetEnumerator()
See https://github.com/Shazwazza/lucenenet/blob/docs-update-jan2020/src/Lucene.Net/Index/FieldInfos.cs/#L168
I'm using sunspot and solr for a rails app to search ebook contens, for highlight feature I have to set the ebook_content as a stored filed, every time I queried solr for result, it sends back the entire document content about the book, which makes the query very slow.
How could I only get the result without the stored field?
The fl parameter of Solr allows you to specify which fields you want returned in the result. If you had fields id, title, ebook_content, then you could use fl=id,title to omit the ebook_content field. I don't think there's support in Solr for getting all fields except one (e.g. -ebook_content).
Update
If you don't want to return the field in the normal results, but still want highlighting on that field, exclude the field as I described above, then turn on the highlighter:
hl=true
set the field(s) which should be highlighted:
hl.fl=ebook_content
and set the size of the highlighting fragment (in characters):
hl.fragsize=50
your finished query looks something like this:
?q=search term&fl=id,title&hl=true&hl.fl=ebook_content&hl.fragsize=50
I've been tasked with learning Lotus Domino Designer - not sure what I did in a previous life, but it must have been pretty bad... - and was wondering how to do a lookup on a database to get some values for selections. As this information could potentially be used in a lot of the applications, I'd prefer it only to be in the one place.
I gather I can use #DBColumn, but what happens if an entry in that lookup changes? If the unique value of the lookup is the text, then the relationship would be broken, wouldn't it? Is there any way of mimicing the idea of relational lookups?
I'm assuming I'm looking at Lotus development from the wrong angle, as this seems to be a real limitation of look ups.
I haven't found any decent learning material on the interwebs, so would appreciate any help.
Ta
You would want to store a unique ID along with the textual value in the source database (not unlike what you would do in an RDBMS). Then, only store that ID in any referencing documents, and use a computed-for-display field to lookup the display value. (There is a performance consideration here - and you could "de-normalize" the data and store the ID and text value in the referencing documents, and do some asynchronous work to keep the values in sync - eg: using a scheduled agent that runs every night or every week).
If DB1 has the key values and DB2 has the documents which will reference these values, then in the form in DB2, you would still do a #DbColumn to lookup your value list. In the lookup view in DB1, concat the text value and ID with a pipe separator (textField + "|" + ID) in the first column. That will tell Notes to store only the ID value (what follows the pipe is the "alias" and is what will be stored).
Note: I would avoid using #DocumentUniqueID as the unique ID for these values, as the Document Unique ID will change if the documents are copied and pasted, or the entire database is copied, etc. You can use the #unique formula function in a computed-when-composed field to generate something close to a unique ID (almost like an identity column in sql).
If you need relational properties, look for non-Notes solutions. It is possible to get some relational behavior using document UNIDs and update agents, but it will be harder than with a proper relational backend.
Your specific problem with referencing to a piece of text that might change can to some extent be resolved by using aliases in the choice fields. If a dialog list contains values on the form...
Foo|id1
Bar|id2
...the form will display Foo but the back-end document will store the value id1 - (and this is what you will be able to show in standard views - although xpages could solve that). Using the #DocumentUniqueID for alias can be a good idea under some circumstances.
It depends on where your using the data. The #DBLookup or #DBColumn will work in Lotus Notes fields if the fields are set to be computed for display. That way they always get the most up to date information when you open the form etc.
If you make it so the data is saved on to the document then you will have to write some update code when you need to refresh the values.
The Lotus Notes help files for designer are pretty good, have a look at that.
SM
You could use a key or alias to store the relationship to your lookup value so if the value itself changes, the connection remains because the alias is intact. For example, if your lookup values were being stored as a collection of documents, I'd have the #DBColumn retrieve Document UNID|lookup value pairs. When in display mode, you could then retrive the value using #GetDocField. If the lookup values are in a different database, then you'd have to retrieve them for display using #DBLookup and construct a view that is keyed off of the UNID or whatever key you decide to use.The only drawback to this technique is that you wouldn't be able to display the field value in views as the actual value isn't stored in the document, just a reference to it. Using XPages, though, you COULD map the relationship into a dynamic datatable just like you would in a truly relational system.
It's tricky, but using LEI, you could also use Notes to front-end a relational backend system, also giving you the dynamic relationship you desire in your lookups.
Hope this helps!
The content of the lookup can change freely. A problem only arises (as it would on any other platform in the same circumstances) if the lookup key changes. You need to use a key that won't change. Human-readable text is an advantage, but if you want to be able to change your key description from, say, "Divisions" to "Business Units" and still have lookups work, you need to use an alias of some kind, which will presumably be mapped to your text description and only used internally. #Unique is pretty good for this, and gives a shortish key, if that is important to you. #DocumentUniqueID is most reliable, but as Ed pointed out, will change (must change - it's a new document) if you copy/paste or make a non-replica copy. This is easy to get around, though. Create a Computed-when-composed field (called, say, "LookupRef") on the form you are using for your reference document with the formula "#DocumentUniqueID". That will capture the ID at the time of creation, and it will not change on copy/paste etc. Use that as your key.