I am trying to issue the following query using Apache Olingo for OData using Java:
URI customersUri = client.newURIBuilder(serviceRoot)
.appendEntitySetSegment("Customers")
.filter("CustomerID eq 'Joe'")
.build();
The expected query string that I want is: $filter=CustomerID eq 'Joe'
However, when the library builds the above URI, the actual query string becomes like this:
%24filter%3DCustomerID+eq+%27Joe%27
Now, the problem is that when I use this query string for my OData Service, it seems that it does not accept the plus (+) signs. However, when removing the plus signs and use space instead, it works
Any help about this or recommendations please? Thanks
This is a bug that was fixed in the V4 4.0.0-beta-03 release. Maybe your client library is out of date.
Related
In Neo4J, I want to use the bolt protocol.
I installed the 3.1 version of Neo4J.
I my Java project, that already works well with normal HTTP Rest API of Neo4J, I integrate with Maven the needed drivers and achieve to perform request with BOLT.
The problem is everywhere you make a search about bolt they give example like this one :
MATCH (a:Product) return a.name
But I don't want the name, I want all the data of all product, what ever i know or not before what are these columns, like here:
MATCH (a:Product) return * --> here I retrieve only the ids of nodes
I found there https://github.com/neo4j-contrib/neo4j-jdbc/tree/master/neo4j-jdbc-bolt we can "flatten" the result but it seems to not work or I didn't understand how it works:
GraphDatabase.driver( "bolt://localhost:7687/?flatten=-1", AuthTokens.basic( "neo4j", "......." ) );
I put the ?flatten=-1 at the end of my connection address... but that changed nothing.
Anyone can help? Or confirm it's not possible or not working ?
Thanks
Ok I understood my error, I didn’t dig enough in the object returned. So used to have a JSON formatted response, I didn’t see that I have to search in the StatementResult object to find the wanted object with its properties. In fact Eclipse in the “expressions” shows “in fly” only the ids, but inside the object data are there.
Record oneRecord = rs.next();
String src = oneRecord.get("m").get("source");
That way I can reconstruct my object
I am facing a strange issue. Looks like a bug in the SolrJ API:
When I try to run a search query with edismax, the "qf" field is not being encoded properly.
I am trying to use this as my "qf" value:
title^40+details_plain^20
SolrQuery.set() method adds this to the query as it is which doesn't work as it needs to be url encoded.
When I url encode it myself, it becomes:
qf=title%5E40+details_plain%5E20
However when I set that in the query, the resulting final query automatically encodes it again and makes it:
qf=title%255E40%2Bdetails_plain%255E20
Which is also wrong and the query fails saying "undefined field text" because Solr doesnt know what I want to search for so it tried to search on the default "text" field.
Here is a snippet from the code:
SolrClient solr=null;
SolrQuery query = new SolrQuery();
solr = new CloudSolrClient(zookeepers, "/" );
query.set("deftype", searchConfig.getDeftype());
//query.set("df", "details_plain"); //unless i uncomment it the query fails as qf is not correct
query.set("fl", searchConfig.getFl());
query.set("mm", searchConfig.getMm());
query.set("qf", searchConfig.getQf());
query.set("rows", searchConfig.getRows());
query.set("q", searchPhrase);
query.set("collection", searchConfig.getCollection_name());
query.set("indent", "on");
query.set("omitHeader", "true");
query.set("wt", "json");
QueryResponse response = solr.query(query);
Why doesn't it encode the original string, but encodes it again if I send it as an encoded string?
I might be overlooking something so let me know what you all think. Am I doing something wrong or should I just get Solr source code and try to fix this myself?
As far as I can remember you should not encode yourself any field. The encode/decode part is transparently handled by solrj.
Solved. Posting the solution here for anyone who might be unfortunate enough to have made the same silly mistake that I did.
The problem was in this line:
query.set("deftype", searchConfig.getDeftype());
the parameter name should be "defType" with a capital T instead of a small t like:
query.set("defType", searchConfig.getDeftype());
Ideally in such services parameter names should be all lowercase so as not to waste peoples time in issues like this but it is what it is. Maybe in a another SOLR version they will make the parameters name ignore case. One can hope!
In my app engine Java application, i want to use RegEx in datastore query to check prefix in one of my fields of DB. I have a column which stores "UserName" . Now i want to implement "Search user" functionality. For that i'll have to use regular expression to which will search users by some particular prefix value.And I referred pattern in Google App engine link.I want to do exactly described in this link. In that they have used Gqlquery with python but i want to implement that in JAVA app engine application. Further i am using this app engine application in my android client. Please any one can help me out to implement Regular Expression` on DataStore. Thank you.
Refering to the Python workaround for "GQL kinda like" queries, the Java implementation with the low level datastore API should look like this :
// From user input
String usernamePrefix = "XX";
Filter usernameGreaterThanPrefixFilter =
new FilterPredicate("username",
FilterOperator.GREATER_THAN_OR_EQUAL,
usernamePrefix);
Filter usernameLessThanLargestPossibleFilter =
new FilterPredicate("username",
FilterOperator.LESS_THAN,
usernamePrefix + "\ufffd");
Filter usernameKindaLikeFilter =
CompositeFilterOperator.and(usernameGreaterThanPrefixFilter, usernameLessThanLargestPossibleFilter);
Query q = new Query("User").setFilter(usernameKindaLikeFilter);
I have never tested this though, if it works I would have learned something thanks to you.
If it does not work, you can always store a fixed length "userPrefix" property on each entity, which would be a substring of the username. You could then query the userPrefix property with a FilterOperator.EQUAL equality filter.
In twitter by using lang operator you can search for retrieving tweets from a particular language: For example, the following search will return tweets only in english:
https://twitter.com/search?q=lang:en
Is there a way to achieve this using twitter api, especially using twitter4j. I know there is a language attribute for search but it also requires at least one keyword to make a search, I would like to search by a particular language without giving any keyword query. The following command in java driver returns the following error:
Query searchQuery = new Query() //
.count(resultsPerPage) //
.since(since)//
.lang("en");
400:The request was invalid. An accompanying error message will explain why. This is the status code will be returned during version 1.0 rate limiting(https://dev.twitter.com/pages/rate-limiting). In API v1.1, a request without authentication is considered invalid and you will get this response.
message - Query parameters are missing
code - 25
Cheers
You must pass the same do you use in the twitter search, your query will be like:
new Query("lang:en")
Using twitter4j,
Query query = new Query();
query.setLang("en");
query.setQuery(searchQuery);
I'm trying to pass an SQL query string from a Java Applet to Servlet as a parameter.
Problem is that in Applet I have something say: sql=select * from p where(+p=1)
The resulting sql parameter in the Servlet is sql=select * from p where(+p=1).
So anyone knows how to prevent the browser from removing the + character from parameters?
Is there a escape character?
Thank you.
Do not EVER do this. This is the direct way for the SQL injection (for example any user can insert the DELETE request to the get string and crash your server)
You can use java.net.URLEncoder for this.
param = URLEncoder.encode(param, "UTF-8");
That said, the whole idea is leaky and very prone to attacks. One could easily reveal the URL and manually send a DELETE FROM p to it. Rather send commands as parameters, not complete SQL queries. Keep and hide the SQL queries in the server side.