Am i heading entirely down the wrong road?
Should this work?
I'm trying to build a query that restricts the selection based on a boolean
e.g. findByIdAndFieldIsTrue(id)
This always returns no values. If I narrow this and just do findById(id) i still get no results which seems odd. I have tried a number of permutations of Id & field in the method name but none work.
Entity {
#Id
String id
boolean field
}
interface EntityRepository BaseRepository, Repository {
findByIdAndFieldIsTrue(id)
}
I tried without the BaseRepository thinking maybe the findOne method was interfering but no luck.
Update:
After adding the logger suggested in the answer I can get the query
{"statement":"SELECT META(`mybucket`).id AS _ID, META(`mybucket`).cas AS _CAS, `mybucket`.* FROM `mybucket` WHERE (`id` = \"entity::9627ff50-531d-4191-a9dc-07b48ba77fe9\") AND `_class` = \"com.myrepo.repository.api.Entity\"","scan_consistency":"statement_plus"}
Edit: N1QL forces you to use the USE KEY construct to select by id... That will be much much harder to integrate, looks like the workaround is the easiest path (see below)
I think this is an overlook of query derivation on the #Id field. In Couchbase, that field maps to the document's key and isn't contained in the document's body, so the N1QL query needs to take that into account.
Can you activate logging for the query generation? There's an AbstractN1qlBasedQuery.class logger that will log the generated N1QL in DEBUG mode. It will allow us to see what the query looks like and confirm that a special step must be taken for the #Id field...
I know it wouldn't be as performant if deserialization is complex, but a workaround could be to use findOne and then check the field.
Got this to work with the following:
#Query("#{#n1ql.selectEntity} WHERE #{#n1ql.filter} AND META(#{#n1ql.bucket}).id IN $1")
List<Entity> findByIdIn(JsonArray ids);
To get the JsonArray from a list do the following:
import com.couchbase.client.java.document.json.JsonArray;
.
.
.
repository.findByIdIn(JsonArray.from(myList));
Related
i am working on aem 6.3 and would like to get page name
SELECT * FROM [cq:Page] WHERE ISDESCENDANTNODE("/content/Product/Silhouettes/Accessories/Bands/Headband")
If I need to retrieve name of the nodes using sql-2 , how do I achieve it?
You can specify column constraints like title, node name, etc this way -
SELECT nodeSet.name, nodeset.title
FROM [cq:Page] AS nodeSet
WHERE ISDESCENDANTNODE("/content/Product/Silhouettes/Accessories/Bands/Headband")
Note: the query tool in AEM(Tools -> Query) will not list the query results according to the columns you've mentioned, it will only list the node paths.
You can look at using /etc/importers/bulkeditor.html or AEM fiddle tool to visualize the query results based on column constraints.
If you want to achieve this programmatically, you can use the same query as you've mentioned in your question and use javax.jcr.query.* and javax.jcr.Node.* API's to retrieve just about any property from the query result. This article here should help you achieve this programatically.
Use the ResourceResolver API to execute and obtain the query results:
final Iterator<Resource> pagesIterator = resolver.findResources('<your_query_here>', javax.jcr.query.Query.JCR_SQL2);
while (pagesIterator.hasNext()) {
final Resource pageResource = pagesIterator.next();
LOG.info(pageResource.getName());
}
However, please note that if you are using any version higher then CQ 5.6, you should use instead the Page API.
In this case, the listChildren(Filter<Page> filter, boolean deep) method will do the job.
The PageFilter parameter may be used if you want to filter through pages of some kind. So if no extra criteria for your page finding algorithm, your may pass null or a new empty object.
The boolean parameter: if false it returns only direct child pages, and if true would list all the descendant pages of the given page.
Therefore, the equivalent solution of the SQL Query which would provide you the same end results would be:
Iterator<Page> rootPageIterator = rootPage.listChildren(null, true);
One of the advantage of Github Search v4 (GraphQL) over v3 is that it can selectively pick the fields that we want, instead of always getting them all. However, the problem I'm facing now is how to get certain fields.
I tried the online help but it is more convolution to me than helpful. Till now, I'm still unable to find the fields for size, score and open issues for the returned repository(ies).
That's why I'm wondering if there is a way to get them all, like Select * in SQL. Thx.
GraphQL requires that when requesting a field that you also request a selection set for that field (one or more fields belonging to that field's type), unless the field resolves to a scalar like a string or number. That means unfortunately there is no syntax for "get all available fields" -- you always have to specify the fields you want the server to return.
Outside of perusing the docs, there's two additional ways you can get a better picture of the fields that are available. One is the GraphQL API Explorer, which lets you try out queries in real time. It's just a GraphiQL interface, which means when you're composing the query, you can trigger the autocomplete feature by pressing Shift+Space or Alt+Space to see a list of available fields.
If you want to look up the fields for a specific type, you can also just ask GraphQL :)
query{
__type(name:"Repository") {
fields {
name
description
type {
kind
name
description
}
args {
name
description
type {
kind
name
description
}
defaultValue
}
}
}
}
Short Answer: No, by design.
GraphQL was designed to have the client explicitly define the data required, leading to one of the primary benefits of GraphQL, which is preventing over fetching.
Technically you can use GraphQL fragments somewhere in your application for every field type, but if you don't know which fields you are trying to get it wouldn't help you.
I'm trying to prepare some boolean query for SOLR engine to find some docs with specific locality field. Results that I get seems to be very weird. I cannot give exactly the same code I use because of security policy in my company but trying to simplify this query:
+(ddm/10973/locality_pl_PL:Gdańsk)
And this query return results as expected with Gdańsk city. But when I add some another condition like this:
+(+(ddm/10973/locality_pl_PL:Gdańsk)+(status:0))
In my results I get docs with city Gdańsk and Gdańsk-Wrzeszcz. Suddenly ":" seems to work as a 'like' not 'equals' as expected.
Does somebody know what could be the reason?
I'm thinking the best way to create an endpoint that one of the filters be a composite key.
Per example, we have a rest service to search for orders:
/orders/
We can filter the orders by start and final date:
/orders?dt-start=2017-05-11T17:12Z&dt-final=2017-05-11T17:12Z
Until here, so far so good. But I would like to filter the orders by customer. The customer is identified by his type of document and number of this document.
So, something like this could be possible:
/orders?type=ID&number=123456789
But the type and number are query parameters that only work together, it's a composite key. But using query parameter - like the last example - seems that the API user can do too:
/orders?number=123456789
/orders?type=ID
But not makes sense. Yes, I could return an error in response (bad request) if only one of these parameters were passed, but this is not natural for who are reading the API endpoint.
Another strategy is combine type and number in the same parameter, but I never see this in any API.
/orders?document=ID-12345678
It's odd to me too. I prefer to use separated parameters instead of this.
So, there are a way to use query parameter and solve this problem in a more "elegant" way?
Thanks!
Don't make up a composite key, instead conditionally require the two params. This ins't bad and IMO is much cleaner than creating a composite key which isn't represented by the data (or resource).
I've done this before, so to help illustrate I'll point you to it. This resource is to query for CyberFacts. The query is bound by a date range. To get data, you can do one of two things.
You can say ?today=true, and get the data for today (equivalent to saying ?startDate=2017-05-13&endDate=2017-05-13)
You can use the startDate and endDate query parameters, however if you use one and not the other (eg ?startDate=2017-05-13) you will receive a 400 Bad Request status response on the query and a error message in the response body.
So in this case I've done a few things to make this work
Make a higher priority parameter (today overrides startDate and endDate)
Document the valid behaviors
Provide appropriate error responses
For you only #2 and #3 would be needed, I think. Not knowing all of your use cases, I would suggest using /orders?type=ID&number=123456789 and document that number is a require query param when type=ID, and also include the appropriate error (eg: "You queried for an Order by Type 'ID', however you did not provide a 'number' query parameter")
How about providing a default value for type, (such as 'ID') as a fallback if the type parameter is absent (I'd probably go for the most common/used document type depending on your situation).
While for the number parameter I would enforce it, i.e. by specifying that it is a required parameter (somewhere in the docs?). If absent, return a bad request.
How can I write a query with ormlite instead of using .create or any other thing like that? Can you please show me how for this simple example :
SELECT name FROM client
EDIT since I can't answer myself :
I guess I had to search a little more , anyway I found how to do it with the QueryBuilder like this :
newDao.query(newDao.queryBuilder().where.eq("name",valueofname)
If someone knows how to write the full query that would be great , otherwise , I'll stick with this solution
How can I write a query with ormlite instead of using .create or any other thing like that?
Goodness, there are tons of documentation about how to do this on the ORMLite site. Here's the section on the query builder.
I'm not sure what you mean by "full query" but your example will work with some tweaks:
List<...> results = newDao.queryBuilder().where().eq("name",valueofname).query();
It does not make sense to just return the name since the Dao hierarchy is designed to return the specific Client object. If you just want the name the you can specify the name column only to return:
... clientDao.queryBuilder().selectColumns("name").where()...
That will return a list of Client objects with just the name field (and the id field if it exists) extracted from the database.
If you just want the name strings then you can use the RawResults feature.