I already followed the link: Set default page size for JPA Pageable Object, but I only see option to set the page-size like spring.data.web.pageable.default-page-size, but I don't see option to page to any customizable value. I know page should start from 0 only, what if I want to override it to other value?
Also, what is the difference between
spring.data.rest.default-page-size and spring.data.web.pageable.default-page-size when to use what option is not clear?
It's not possible to set the default start page. This is always 0.
If you use Spring Data REST Repositories https://spring.io/projects/spring-data-rest you must use spring.data.rest.default-page-size in all other cases spring.data.web.pageable.default-page-size
Related
For a weblog I am trying to get the top 10 popular posts from for example the last month. I figured I'd get the data out of Matomo, as that's already tracking visits and has an API. I've never used this API before though, so I've been reading the documentation and trying out some things. I am able to get data from the API using the Actions.getPageUrls method. However, when I try to filter using segment=^http://example.org/post I still get data from other URL's. It looks like it filters on session and gives back all data from the sessions that have at least 1 page that conforms to the filter.
The full URL I'm using is: http://example.org/matomo/index.php?&module=API&token_auth=12345&method=Actions.getPageUrls&format=json&idSite=1&period=month&date=today&expanded=1&segment=pageUrl%3D%5Ehttp%253A%252F%252Fexample.org%252Fpost. I've also tried with less and no URL encoding for the segment, but that doesn't seem to make a difference. If I use a URL that doesn't exist I get an empty array returned.
Am I doing something wrong? Is there a different way to only get the top pages with a URL starting with http://example.org/post? Or do I have to sift through the data myself to only get the pages I want?
I am using Matomo version 3.13.5.
I figured it out. There is no need to use segment. This can be achieved using the flat, filter_column and filter_pattern parameters.
Setting flat=1 will make it so all pages are returned in a single array, instead of hierarchically.
With filter_column and filter_pattern I can filter the results.
The URL I use now is: http://example.org/matomo/index.php?&module=API&token_auth=12345&method=Actions.getPageUrls&format=json&idSite=1&period=month&date=today&flat=1&filter_column=label&filter_pattern=%5E%2Fpost%2F. This does exactly what I want.
The unencoded pattern is ^/post/, so this will filter out any page that does not start with /post/.
I want to understand utility of isExecuted() in ADF's ViewObjectImpl class.
The documentation is very sparse(Indicates whether the row set has been executed or not) and I couldn't get my doubts cleared.
As per documentation, only if row set is executed at least once it will return true. But, I am seeing that as soon as my application module is created, a view Object which is housed in the application module, is returning "isExecuted() = true " .. Is this expected or is there any setting because of which this is happening ?
It is hard to see purely via the Application Module Tester.
But if you have data controls based on your AM and use them on an interface (such as a UI page), you can check the working of the isExecuted method.
On your user interface, you can create a basic page that does not bind to any of the data controls based on the VO's - but only to a simple AM operation that you expose via AM's client interface:
public void showIsExecuted() {
System.out.println("*******TestAppModuleImpl::showIsExecuted() DepartmentsView1:" + this.getDepartmentsView1().isExecuted());
System.out.println("*******TestAppModuleImpl::showIsExecuted() DepartmentsView2:" + this.getDepartmentsView1().isExecuted());
System.out.println("*******TestAppModuleImpl::showIsExecuted() ViewObj1:" + this.getViewObj1().isExecuted());
}
On a UI page (view1.jsf), you call only this method without using any of the VO based data controls and your output should show this:
*******TestAppModuleImpl::showIsExecuted() DepartmentsView1:false
*******TestAppModuleImpl::showIsExecuted() DepartmentsView2:false
*******TestAppModuleImpl::showIsExecuted() ViewObj1:false
Now, on another UI page (e.g. view2.jsf), show some of the data from one or more of the VO's and also a button for the custom AM function. After running the page, you should get the below in logs (as expected):
*******TestAppModuleImpl::showIsExecuted() DepartmentsView1:true
*******TestAppModuleImpl::showIsExecuted() DepartmentsView2:true
*******TestAppModuleImpl::showIsExecuted() ViewObj1:false
For reference, this is what my design time setup (in JDeveloper 12.2.1.1) looks like :
Also, you can further tweak the options under AM -> General -> Tuning -> Customize Runtime Instantiation Behaviour
So this is weird, wondering if perhaps SFDC is just returning "wrong" information.
I'm working with layouts for an object, and in the interface I have set a field in the default layout (there are no other layouts) to "required".
But, when I retrieve this layout from the API, the field in question's "nillable" attribute is TRUE when it should be FALSE.
Does salesforce expect data like this to be retrieved from somewhere else? Regardless it seems the API is lying.
The API is not lying - the field is only required by that particular layout, not by the underlying system.
If you want it to truly be required, you need to set this attribute on the field itself.
I have been trying to create a component like the Bakery's Paginator Recall that would allow me to save pagination data for CakePHP 2.4 and run into the following issue.
All solutions involve saving the Paginator parameters in the session and then retrieving and applying them upon returning to that same page without specifying any.
This approach would have worked if only the Paginator helper functions like numbers(), first() and previous() would include the page:1 named parameter in the links that they generate for moving to the first page like the corresponding function of the 1.3 version.
Unfortunately all of these functions create URLs without the page parameter when they refer to the first page, so when users click on the first page link, the component does not find any paging info and hence it returns them to the previous position.
There must be some way to work around this, but for the moment I am completely stuck.
NOT including the page number in the link to the first page is by design.
Read the reason on the CakePHP 2.4 Migration guide.
I would suggest to use the same convention. When you do not have pagination information assume is page one, and do not add it to your URLs.
So all you have to do is code this special case when then pagination is missing. And in this special case your "recall" component will simply not add that page.
I believe that I have managed to create a working solution. Thanks to the advice I have received I have now created a working component like the original PaginationRecallCompoent.
I have written all the details in the following blog post.
I have a web application that uses SOLR as backend search service.
All requests that control searches are GET requests: user does something (type something, choose a page size, a sort critera) and, after pressing the search button, a corresponding servlet on the web app calls SOLR.
Now, the parameters sent to my servlet are exposed in the browser address bar; this is good because
1) each page on the webapp can be stored as permalink
2) the search can be controlled by changing directly the URL
On top of that, for a specific parameter, the page size, I would like to impose some constraint. I mean: if the select menu on the web app proposes 3 choices (5,10,15) I don't want other values.
Now, I know I can do that in my servlet but I was wondering if it is possible on SOLR side too...local params? don't know.
Briefly: the "rows" parameters on SOLR must be 5,10 or 20: if a value > 20 comes then 20 is applied.
Within Solr SearchHandlers you can predefine some configuration settings as outlined in the Configuration section. This allows you to set the following parameter behaviors
defaults - provides default param values that will be used if the param does not have a value specified at request time.
appends - provides param values that will be used in addition to any values specified at request time (or as defaults.
invariants - provides param values that will be used in spite of any values provided at request time. They are a way of letting the Solr maintainer lock down the options available to Solr clients. Any params values specified here are used regardless of what values may be specified in either the query, the "defaults", or the "appends" params.
However, these three options, do not provide for the specific behavior of limiting the rows value to 20 like you are seeking. I believe the only way to limit this within Solr would be to create a custom Request Handler and plug that into Solr. The article - Developing a Request Handler for Solr provides a good overview of the steps needed to create you own Request Handler.