Current documentation states: "The max size of a searchable field is restricted to 10922 characters. This constraint is enforced at both product creation and product update. If the length of the input exceeds the maximum size an InvalidField error is returned"
If i have localized field/attribute of type "ltext" will constraint be applied for each localized value or on total length of all localized values of an attribute?
Localized text is modeled as an object with field for every language tag. This means that the constraint would be applied individually on every localized value.
Related
I went through the Java-doc # DocExpirationUpdateProcessorFactory . It says :
The DocExpirationUpdateProcessorFactory provides two features related
to the "expiration" of documents which can be used individually, or in
combination:
Computing expiration field values for documents from a "time to live" (TTL)
Periodically delete documents from the index based on an expiration field
But it didn't specify how expirationField values are calculated from ttl field.
Anybody can help to understand how its calculated?
ttlFieldName - Name of a field this process should look for in each document processed, defaulting to _ttl_. If the specified field name exists in a document, the document field value will be parsed as a Date Math Expression relative to NOW and the result will be added to the document using the expirationFieldName.
This means that you can use terms like +2 HOURS in the _ttl_ field to make the document expire in two hours from when it was indexed. This date value will then be stored in the expirationFieldName field.
From Cloudera's documentation about the introduction of the feature:
Current Time is: 2016-10-26 20:14:00
_ttl_ is defined as: +2HOURS
This will result in an expiration value of 2016-10-26 22:14:00
There are also more examples in Lucidworks description of the feature:
{ "id" : "live_2_minutes_b",
"time_to_live_s" : "+120SECONDS"
},
I'm looking at a very old solr instance (4-6 years since last touched), and I am seeing these extra dynamic fields, 'f_' and 'fs_' for multi and single valued facet fields.
My understanding, though, is that facets only happen in query-time.
Also, it's just a copy over - the fields dont change type.
So before I nuke these fields to kingdom come; is there a reason for facet fields in an index that is just a copied field?
Thanks
Facets only happening query time is a bit of a misnomer - the content (the tokens) that the facet represents from is generated when indexing. The facet gives the distinct number of documents that has a specific token present.
That means that if the field type is identical and there is only one field being copied into the other named field, the behaviour between the source and the destination field should be identical.
However, if there are multiple fields copying content into the same field, the results will differ. Also be aware that the type is given from the schema for the field, it's not changed by the copyField instruction in any way. A copy field operation happens before any content runs through the indexing chain for the field.
Usually you want facets to be generated on string fields so that the indexed values are kept as-is, while you want to use a text field or similar for searching (with tokenization), since a string field would only give exact (including matching case) hits.
Im wondering how to best guarantee that a field is unique and isn't saved to the datastore if it isn't. Also that it should be required. I am using this field as stringID and need it to be unique. I know that I can simply try to get an entity by this field and see if it exists and build a logic around it. But is there a simpler way like declaring in your struct that the field should be unique and/or required? Like the mockup below.
type Car struct {
Regnr string "required" "unique"
}
Thanks!
From the Datastore API:
By default, for struct pointers, all properties are potentially
indexed, and the property name is the same as the field name (and
hence must start with an upper case letter). Fields may have a
datastore:"name,options" tag. The tag name is the property name,
which must be one or more valid Go identifiers joined by ".", but may
start with a lower case letter. An empty tag name means to just use
the field name. A "-" tag name means that the datastore will ignore
that field. If options is "noindex" then the field will not be
indexed. If the options is "" then the comma may be omitted. There are
no other recognized options.
Not possible to set those type of tags with Datastore.
How can I change this query to find only records with numeric value of telephoneNumber attribute?
(&(objectClass=user)(telephoneNumber=*)(MemberOf=CN=Users,OU=Groups,DC=domain,DC=local))"
I have to be sure that this field contains only digits.
You can't do that with an LDAP filter.
You may however be able to constrain the attribute, so that non-numerical never get in there in the first place.
My existing Solr 4.x instance has about 650k documents indexed. I just added a new field to the schema that will hold a number of votes given to the document that will be used in boosting the score. Until the first user up votes (or down votes) a given document, said document will not have that field defined. You can see this when viewing the document using the Solr Admin tool.
The field was defined with a default value but I think this only applies to new documents (or maybe reindexed documents) that do not have said field specified.
When I try to test out different boosting functions, I get the following exception back
"error": {
"msg": "can not use FieldCache on a field which is neither indexed nor has doc values: votes",
"code": 400
}
Is it possible to specify a default value to be used for boosting when the field does not (yet) exist in the document? My logic would be
field exists -- use field value
field does not exist -- use default value
This seems to related to your earlier question. Perhaps you can try the FuntionQuery as well
q={!boost b=map(field,0,0,0,default_value) } your_query
This will boost based on the field value, and use default_value if the field value is null.
Reference here