I am using jQuery to get information from SharePoint 2010's listData.svc. I noticed some inconsistencies with regards to case sensitivity in my queries:
The following command is case sensitive:
...&$filter=substringof('String', property) eq True
The following command is case insensitive
...&$filter=substringof(tolower('String'), tolower(property)) eq True
The following command is also case insensitive but much shorter:
...&$filter=substringof('String', property) or substringof('String', property2)
However, the case insensitivity using the short method is lost for the entire filter when one part is using a property more than two levels down. So in the following command the entire filter becomes case sensitive again:
...&$filter=substringof('String', property/property/property) or substringof('String', property2)
Is this an issue with SharePoint's service? Or am I just doing something wrong?
It seems like a bug in ListData.svc.
If comparisons (delegated to SQL server at the end of the day) are case-sensitive in any query they should always be case-sensitive.
Clearly the tolower call makes things match whether cases match or not, so we can ignore that.
However I have no idea why doing an OR on another property works.
Either it is a bug in SharePoint or perhaps you've inadvertantly picked an OR clause that returns the data your were expecting by accident.
Related
I want to perform a full-text-search on 2 columns with partial queries included.
I've tried multiple options and this one seems the best to me:
Add <-> between the words of the query and :* at the end
Execute query
The problem is, that I have to execute the query in TypeORM. So when I use to_tsquery(:query) there might be invalid syntax in the query, which produces an error.
The function plainto_tsquery() would be perfect since it prevents invalid syntax in the argument, but at the same time it prevents the partial queries, which I can do as described.
Any idea how I could combine the best of the to worlds?
You could try something like
SELECT to_tsquery(quote_literal(query) || ':*')
This will add <-> between word and :* at the end of every word, while quote_literal should protect you from syntax issues by escaping the text.
Disadvantage of this method however is that the generated query might behave unexpectedly when encountering queries with symbols, e.g. o'reilley as query will yield 'o':* <-> 'reilley':* as tsquery, which likely won't give back the expected result. Unfortunately, the only solution I know for this is cleaning both the input and text data of any symbols.
In Freemarker, I have a Map<Map<...>> in the model.
Due to FM glitch, querying for 2nd level Map needs ?api. However, that escapes the normal value existence checks and complicates things.
This is what I have:
<#if sortedStatsMap[rowTag.name]?? && sortedStatsMap[rowTag.name]?is_hash>
${mapToJson(sortedStatsMap[rowTag.name]?api.get(boxTag.name))!}
</#if>
This ends up with:
APINotSupportedTemplateException: The value doesn't support ?api. See requirements in the FreeMarker Manual.
(FTL type: sequence+extended_hash+string (wrapper: f.c.DefaultToExpression$EmptyStringAndSequence),
TemplateModel class: f.c.DefaultToExpression$EmptyStringAndSequence,
ObjectWapper: freemarker.template.DefaultObjectWrapper#1074040321(2.3.26, useAdaptersForContainers=true, forceLegacyNonListCollections=true, iterableSupport=trueexposureLevel=1, exposeFields=false, treatDefaultMethodsAsBeanMembers=true, sharedClassIntrospCache=#1896185155, ...))
The blamed expression:
==> sortedStatsMap[rowTag.name]! [in template "reports/templates/techReport-boxes.ftl" at line 152, column 84]
If I try
sortedStatsMap[rowTag.name]!?is_hash
then this also fails because if missing, it gives me empty_string_and_sequence and ?is_hash can't be applied, reportedly. (Says that in an error.)
What's the proper logic to check whether I can use ?api.get(key)? Or the right way to use ! to handle missing values or a missing key?
You can check if a value supports ?api with ?has_api. Though maybe you don't need that; the example and the problems related to it should be clarified (see my comments).
I was trying to set index type from exact to fulltext in neo4j shell, so i can do incasesensitive search with lucene query. So i used this command:
index --set-config Destination type fulltext
but it didn't work. Still couldn't do case insensitive search, so a played around and change some other values, like _blueprints:type and to_lower_case.
That didn't do any good.
Now it somehow ignores first character of name value ( weird ! ) . So if i am searching for "London" for example and i type "Lon" it returns nothing. But if i type "ond" it returns the node. The same for every node.
I tried setting everything back to normal. Didn`t help.
What did i mess up? What am i missing?
I am using a Everyman PHP library to communicate with database.
I created new index with "to_lower_case" property.
I think that will solve my problem, just have to convert string to lower case before inserting it into query. It seems to work.
Setting configuration afterwards doesn't update already indexed values (as the shell notes, I think). If you've created your index with "to_lower_case=true" then additions as well as queries will have the values converted to lower case. Calling Index#get will still require you to lower-case it yourself.
I need to get the data from cassandra with out case sensitive. Please help me.
There is no case-sensitivity concept in Cassandra. All the data is stored as byte[], so it's not even a String.
You can make a custom comparator (see the API) which transforms byte[] to String and disregards case.
The other thing to do is just get the data and transform it on the client side.
Actually, your question is quite unclear as of what is your goal, so I can't give more details.
Update: Run a one-time job that fetches all records from the db and updates them, setting to lower-case. Then continue inserting everything with lowercase.
This has been resolved if you have SOLR enabled using:
CREATE SEARCH INDEX ON tableName WITH COLUMNS *, camelCaseColumn { lowerCase : true };
An index is created that allows the select statement to use lowercase in the where clause. For more details search for LowerCaseStrField.
if strValue = 'Hello' then what would be the value of (strValue <> 'HELLO') be?
It depends on how you use the Option Compare statement. It can work either way.
Option Compare Text 'Case insensitive'
Option Compare Binary 'Case sensitive (default)'
Here's a VB6 string tutorial.
No, it's case sensitive (by default at least though you'll want to check - if Option Compare is set to Binary or not set then it's case sensitive, if it's set to text then it's case insensitive).
Lcase() both sides if you'd rather it were case insensitive.
The reason I prefer this to changing / setting option compare is that someone looking at the code doesn't have to go hunting to see what option compare is set to to understand how it's going to behave BUT it's almost certainly slower (not significantly unless you're calling it repeatedly) and some might see it as not particularly neat.
The documentation is fairly clear
If you use Option Compare Text in the Declarations section of a
module [the top of the file], string comparisons aren't case-sensitive.
If you use Option Compare Binary, comparisons are case-sensitive.
If you use Option Compare Database [only valid in Access VBA], the comparison method is set by the current database.