nexus-public
nexus-public copied to clipboard
sonatype
NEXUS-17451 - add optional limit request parameter to REST APIs
One of the requirements of the issue is that a maximum limit be enforced.
This PR appears to allow changing the limit to whatever is the whim of the caller. For that reason I don't think we accept this PR before such a max limit is enforced.
Unfortunately I don't think we have identified a max limit we are comfortable with.
I imagined the max limit should be a configuration setting, though adding a configuration setting seems to be non-trivial as it would most likely need to be set in the UI somewhere, though the UI doesn't have global configuration settings anywhere for something like this.
Any update on this PR? We also have a lot of components and this pagination force us to to hundreds of calls to retrieve them
Any update on this PR? We also have a lot of components and this pagination force us to to hundreds of calls to retrieve them
I have to deal with quite big repository, i'm going to call /v1/components endpoint almost 5 THOUSAND times as low as 100 items per call would be a great improvement!
@peterlynch @ruckc We're sitting in the same boat. We have several scripts that regularly use the Nexus API to do various tasks and this change would dramatically cut down their running time and impact on the network.
We have the same problem, I have to run about 1800 requests to get all our assets from one repo. Only the assets to get takes about 30min.
If you haven't, suggest putting weight (comments, votes) on https://issues.sonatype.org/browse/NEXUS-17451 itself. I don't know how regularly (if at all) leadership looks at these PRs except when weighing interest.
This would be amazing. Any movement on this? Our use case is that we want to download all artifacts and upload them to a new upgraded nexus instance. This would be ideal to help speed up the hours spent trying to pull down the artifact names and versions.
Just a suggestion we can also add a @Max(100). I would propose a max of 500 if the server can handle it within a reasonable response rate as to not timeout. We have a very large amount of components.
Agreed that this would be an excellent addition to the API. A hard-coded 10 items per response is very low...
I would also like to have this. The default value is extremely low, causing a really slow listing. It is slow on low latency links (<1ms from client to nexus) and insanly slow on high latency links (>200ms). We have 20k assets, and it takes few minutes to list them, but I need to do it every few minutes. I would like to use something like page size of 200 or 1000, instead of 10. I think max 1000 is a good limit. For example AWS S3 uses 1000 as pagination limit, which is reasonable.
What happened?
Looks like @ruckc just tired to wait almost 3 years for Sonatype to approve and merge his PR.
Unfortunately, this is a huge problem for many of us, who has a pretty big Nexus instance. In our case, we have almost 170k of packages that we need to index periodically. Somebody writes about 30 mins or even 1 hour of taking components and assets. Share your pain guys, in our case it takes days. :(
I got tired of the sheer number of security updates coming out of dependabot. I have also given up on Sonatype making any kind of user improvements. My company was evening a paying customer for a while and they couldn't prioritize anything even with support.
Wish everyone luck that needs this. You might get it by 2030.
What happened?
Looks like @ruckc just tired to wait almost 3 years for Sonatype to approve and merge his PR.
Unfortunately, this is a huge problem for many of us, who has a pretty big Nexus instance. In our case, we have almost 170k of packages that we need to index periodically. Somebody writes about 30 mins or even 1 hour of taking components and assets. Share your pain guys, in our case it takes days. :(
What kind of repo is it? For RPM/DEB/Nuget we ended up dealing with the indexes ourselves instead of using the API ....
I got tired of the sheer number of security updates coming out of dependabot. I have also given up on Sonatype making any kind of user improvements. My company was evening a paying customer for a while and they couldn't prioritize anything even with support.
Wish everyone luck that needs this. You might get it by 2030.
Yeah, they don't seem very responsive at all. Too bad.
What happened?
Looks like @ruckc just tired to wait almost 3 years for Sonatype to approve and merge his PR. Unfortunately, this is a huge problem for many of us, who has a pretty big Nexus instance. In our case, we have almost 170k of packages that we need to index periodically. Somebody writes about 30 mins or even 1 hour of taking components and assets. Share your pain guys, in our case it takes days. :(
What kind of repo is it? For RPM/DEB/Nuget we ended up dealing with the indexes ourselves instead of using the API ....
NuGet. The reason – too slow to get data from Nexus with API, and it's much faster if you have some outer index to work with and update it periodically.
NuGet. The reason – too slow to get data from Nexus with API, and it's much faster if you have some outer index to work with and update it periodically.
Have you tried checking against the v3 indexes or if you are using v2, against the OData API (yes deprecated in nuget.org but still) ? That should be fast.
NuGet. The reason – too slow to get data from Nexus with API, and it's much faster if you have some outer index to work with and update it periodically.
Have you tried checking against the v3 indexes or if you are using v2, against the OData API (yes deprecated in nuget.org but still) ? That should be fast.
Unfortunately, Nexus does not realize a catalogue API endpoint to list all packages. As far as I know, only nuget gallery on nuget.org have such thing.