When I fetch all results without pagination result is OK but when use pagination appear problem in pagination metadata
Page p=PageImpl(result.getResults(), PageRequest.of(pageNo, pageSize), result.getTotal())
p.getTotalElements() // wrong result
p.result.getTotalPages() // also is wrong
code snippet:-
QOrderAppliedTax qTax = QOrderAppliedTax.orderAppliedTax;
QOrderDetails qOrderDetails = QOrderDetails.orderDetails;
NumberExpression<Integer> groupBy = qOrderDetails.createdDate.yearWeek();
StringPath name = qTax.name;
NumberExpression<Double> totalTaxValue = qTax.value.sum();
NumberExpression<Long> ordersCount = qOrderDetails.order.countDistinct();
DateTimeExpression<Date> fromDate = qOrderDetails.createdDate.min();
DateTimeExpression<Date> toDate = qOrderDetails.createdDate.max();
CriteriaBuilderFactory cbf = Criteria.getDefault().createCriteriaBuilderFactory(entityManagerFactory);
QueryResults<TaxDto> result= new BlazeJPAQuery<>(em, cbf)
.select(Projections.constructor(TaxDto.class, fromDate, toDate, groupBy, name, totalTaxValue,
ordersCount))
.from(qTax).innerJoin(qOrderDetails).on(qTax.orderDetails.eq(qOrderDetails))
.groupBy(taxName, groupBy).offset(pageNo * pageSize).limit(pageSize).fetchResults();
the wrong result appears even I used
orderBy(groupBy.asc(), taxName.asc())
exactly the two fields in order by is unique together.
This issue turned out to be a bug which will be resolved in Blaze-Persistence 1.6.3 (expected soon). The patch has already landed in 1.6.3-SNAPSHOT.
Related
I am trying to get data by pagination from CosmosTemplate.paginationQuery(), but the problem is I am not getting data from the offset that I am setting in pagination object. Below is my code for setting pagination,
DocumentQuery documentQuery = new DocumentQuery(criteriaList, CriteriaType.AND));
if (Objects.nonNull(Offset) && Objects.nonNull(limit)) {
PageRequest cosmosPageRequest = CosmosPageRequest.of(Offset, limit);
documentQuery.with(cosmosPageRequest);
Page<User> page = cosmosTemplate.paginationQuery(documentQuery, User.class, COLLECTION_NAME);
...
}
This always returns me list with first set of objects. So for example when I am setting offset as 11 and limit 10, it is always returning me records with offset 0 to 10. I tried to check library as well but there also no where they are setting offset while retrieving records. Below is the code for the same form azure-cosmosdb library AbstractQueryGenerator.generateCosmosQuery().
protected SqlQuerySpec generateCosmosQuery(#NonNull CosmosQuery query,
#NonNull String queryHead) {
final Pair<String, List<Pair<String, Object>>> queryBody = generateQueryBody(query);
String queryString = String.join(" ", queryHead, queryBody.getFirst(), generateQueryTail(query));
final List<Pair<String, Object>> parameters = queryBody.getSecond();
List<SqlParameter> sqlParameters = parameters.stream()
.map(p -> new SqlParameter("#" + p.getFirst(),
toCosmosDbValue(p.getSecond())))
.collect(Collectors.toList());
if (query.getLimit() > 0) {
queryString = new StringBuilder(queryString)
.append("OFFSET 0 LIMIT ")
.append(query.getLimit()).toString();
}
return new SqlQuerySpec(queryString, sqlParameters);
}
Over here also hard coding for offset is done instead of taking from pagination object. Please can anyone suggest if I am doing anything wrong or getting records based on offset is not supported in this library.
This is a bug in the azure-spring-data-cosmos SDK, where it does not honor the OFFSET as part of CosmosPageRequest and always set it to 0.
It is currently being investigated and will be fixed soon. Follow this issue for updates - https://github.com/Azure/azure-sdk-for-java/issues/28032
However, as a workaround for now, the best way would be to use a custom query using query annotation as mentioned in this example - Usage of offset - https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/cosmos/azure-spring-data-cosmos-test/src/test/java/com/azure/spring/data/cosmos/repository/integration/ContactRepositoryIT.java#L235
Query annotation - https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/cosmos/azure-spring-data-cosmos-test/src/test/java/com/azure/spring/data/cosmos/repository/repository/ContactRepository.java#L39
I'm using JCypher 4.2.0 with Neo4J Server 4.0.2 with the builtin Movie graph.
I'm trying to unite couple simple, independent queries to one bigger for my needs.
first query: MATCH (people:Person) RETURN people.name, second query: MATCH (m:Movie) WHERE m.title = "Apollo 13" RETURN m.title.
and in JCypher:
JcNode
people = new JcNode("people"),
m = new JcNode("m");
JcQuery
query1 = new JcQuery(new IClause[]{
MATCH.node(people).label("Person"),
RETURN.value(people.property("name"))
}),
query2 = new JcQuery(new IClause[]{
MATCH.node(m).label("Movie"),
WHERE.valueOf(m.property("title")).EQUALS("Apollo 13")
RETURN.value(m.property("title"))
});
Of course, m.title should return only 1 result.
is it possible?
I have the following info stored in Marklogic for the json files as follows.
1.json>> "dateSubmitted" : "2017/10/11 09:15:14"
2.json>> "dateSubmitted" : "2017/10/11 10:13:14"
3.json>> "dateSubmitted" : "2017/10/14 11:12:13"
My query term is:
String dateQuery = "2017/10/11";
I tried 2 methods and none seems to be working.
Method 1:
StructuredQueryBuilder qb = new StructuredQueryBuilder();
QueryDefinition queryDef = qb.and(qb.word((qb.jsonProperty("dateSubmitted"),dateQuery)));
queryDef.setDirectory(DIRECTORY);
SearchHandle resultsHandle = new SearchHandle();
queryManager.search(queryDef, resultsHandle, start);
Method 2:
StructuredQueryBuilder qb = new StructuredQueryBuilder();
String[] wordQueryOptions = {"punctuation-sensitive", "space-sensitive"};
QueryDefinition queryDef = qb.and(qb.word((qb.jsonProperty("dateSubmitted"),
FragmentScope.DOCUMENTS,
wordQueryOptions,100.0,dateQuery)));
queryDef.setDirectory(DIRECTORY);
SearchHandle resultsHandle = new SearchHandle();
queryManager.search(queryDef, resultsHandle, start);
The expected result is to return only 1.json and 2.json.
However 3.json was also returned.
Is there some settings I'm missing in my Marklogic admin to activate options or punctuation-sensitive?
Working with dates is often easier and more powerful if you index the property as a date. That way, you can do before and after matches on the date as well as sort on the date.
To index a property as a date, you can create a range index on the date. You can then use a range query on the date.
In MarkLogic 9, you can also use TDE to project rows from the documents with a column for the dates.
Hoping that helps,
I've spent days trying to find out how to save or update a value into a CustomField programmatically and finally found out how it's done. So I'll make this a question and then answer it as I would have loved to have this question and answer.
There is conflicting documentation on how to save or update a value for a Custom Field in JIRA. I was using:
customField.setCustomFieldValue(CustomField, value);
This does not save the value into the database but it does update the value as far as I can tell. It's only useful if you are using the CustomField further down in a Workflow Post Function transition for example.
I'm using Jira 4.3.2.
How do I persist the the CustomFields value into the JIRA database?
Ok, this is how I'm successfully updating and saving the CustomField value into the JIRA db.
Comments welcome...
private void saveValue(MutableIssue issue, String valueToSave, CustomField
customField) throws FieldLayoutStorageException {
issue.setCustomFieldValue(customField, valueToSave);
Map<String, ModifiedValue> modifiedFields = issue.getModifiedFields();
FieldLayoutItem fieldLayoutItem =
ComponentManager.getInstance().getFieldLayoutManager().getFieldLayout(issue).getFieldLayoutItem(
customField);
DefaultIssueChangeHolder issueChangeHolder = new DefaultIssueChangeHolder();
final ModifiedValue modifiedValue = (ModifiedValue) modifiedFields.get(customField.getId());
customField.updateValue(fieldLayoutItem, issue, modifiedValue, issueChangeHolder);
}
Here is how I do it (for a custom field I programmatically store a random UUID in):
CustomField cfHash = customFieldManager.getCustomFieldObjectByName(...);
IssueChangeHolder changeHolder = new DefaultIssueChangeHolder();
try {
Object newHashValue = java.util.UUID.randomUUID().toString();
Object oldHashValue = issue.getCustomFieldValue(cfHash);
issue.setCustomFieldValue(cfHash, newHashValue);
cfHash.updateValue(null, issue, new ModifiedValue(oldHashValue, newHashValue), changeHolder);
...
More or less the same as you but with another way to get the ModifiedValue-Object.
Here a solution that works for me in JIRA 6.4.7 to update a custom field value. Actually Im updating a single select field, therefore I have to get the Option for it:
MutableIssue issue = issueManager.getIssueByCurrentKey(issueKey);
FieldConfig relevantConfig = customField.getRelevantConfig(issue);
// if you use a text field use String. or double for numeric
Option optionForValue = optionsManager.getOptions(relevantConfig).getOptionForValue(option, null);
issue.setCustomFieldValue(customField,optionForValue);
Map<String, ModifiedValue> modifiedFields = issue.getModifiedFields();
FieldLayoutItem fieldLayoutItem =
fieldLayoutManager.getFieldLayout(issue).getFieldLayoutItem(customField);
DefaultIssueChangeHolder issueChangeHolder = new DefaultIssueChangeHolder();
final ModifiedValue modifiedValue = modifiedFields.get(customField.getId());
customField.updateValue(fieldLayoutItem, issue, modifiedValue, issueChangeHolder);
I had the same issue and had it resolved using this plugin, fyi=)
The result list is perfect but the getResultSize() is incorrect.
I've knocked up some code to illustrate.
Criteria criteria2 = this.getSession().createCriteria(Film.class);
Criterion genre = Restrictions.eq("genreAlias.genreName", details.getSearch().getGenreName());
criteria2.createAlias("genres", "genreAlias", CriteriaSpecification.INNER_JOIN);
criteria2.add(genre);
criteria2.setMaxResults(details.getMaxRows())
.setFirstResult(details.getStartResult());
FullTextEntityManager fullTextEntityManager = org.hibernate.search.jpa.Search.createFullTextEntityManager(entityManager);
org.apache.lucene.queryParser.QueryParser parser2 = new QueryParser("title", new StopAnalyzer() );
org.apache.lucene.search.Query luceneQuery2 = parser2.parse( "title:"+details.getSearch()");
FullTextQuery fullTextQuery = fullTextEntityManager.createFullTextQuery( luceneQuery2, Film.class);
fullTextQuery.setCriteriaQuery(criteria2);
fullTextQuery.getResultList()); // Returns the correctly filtered list
fullTextQuery.getResultSize()); // Returns the retsult size without the genre resrtiction
From http://docs.jboss.org/hibernate/search/3.3/api/org/hibernate/search/jpa/FullTextQuery.html
int getResultSize()
Returns the number of hits for this search Caution: The number of results might be slightly different from getResultList().size() because getResultList() may be not in sync with the database at the time of query.
You should try to use some of the more specialized queries like this one:
Query query = new FuzzyQuery(new Term("title", q));
FullTextQuery fullTextQuery = fullTextSession.createFullTextQuery(query, Film.class);
int filmCount = fullTextQuery.getResultSize();
and this is how you do pagination requests (I'm guessing you have improperly implemented your paggination):
FullTextQuery hits = Search.getFullTextSession(getSession()).createFullTextQuery(query, Film.class)
.setFirstResult((pageNumber - 1) * perPageItems).setMaxResults(perPageItems);
The above works for me every time. You should keep in mind that the result of getResultSize() more of estimate. I use pagination a lot and I have experienced the number changing between pages. So you should say "about xxxx" results.