Content conv3 = as.find()
.withContainerId(ContentId.of(pageCEO.getId()))
.withFilename("file.txt")
.fetchMany(new SimplePageRequest(0, Integer.MAX_VALUE))
.getResults()
.stream()
.filter(f -> f.getVersion().getNumber() == 3)
.findFirst()
.orElse(null);
That looks very ugly but I think it should achieve the same goal, except now I’m getting instance of Content instead of Attachment which is a problem for me, I would need to have the corresponding Attachment-instance.
So, how do I now read the contents from the Content-instance? Is there a way to get an InputStream from it?
I also noticed in the documentation that ContentSelector should be used if specific version is to be retrieved, which sounds like better way to get the desired version instead of the fetching all and filtering the results, but I can’t figure out how exactly ContentSelector is supposed to be used, i.e. I can’t see any place where it can be used as parameter for the fetching.
Any tutorial or example code of above usage of getting specific attachment version contents would be very much appreciated.
Bumping this back to the top as the request is still outstanding for Any tutorial or example code of above usage of getting specific attachment version contents would be very much appreciated.
Thank you
To further bump, AttachmentManager.getAttachment is deprecated. AttachmentService is annotated as @ExperimentalApi.
I can’t find any way to read the attachment contents using AttachmentManger. Looking at the source code AttachmentService uses AttachmentManagerInternal to create and update attachments.
AttachmentService also doesn’t support minorEdit for noiseless deletion, API Notifications for Removing Attachments
So, which is the recommended API, manager or service, deprecated or experimental?
I’m with everyone here.
The simple one-method Confluence APIs for getting things by ID, name, version, etc. have been deprecated in favor of search/find APIs that pretty much need a code example to figure out. And there are no code examples.
Here is what I have been thinking: please do not throw away simple APIs for doing common things like getting a single object that matches some unique identifier. Getting a single object using a unique identifier should be a single method call, not a mass of search/process code.
Expose the new search/find APIs along with documentation and code examples. They will only be used by the plugins that want to do more complex things. Leave the simple APIs where they are… swap out the underlying impl w/ the new impl that the complex search APIs are exercising and leave the simple interfaces alone. Encapsulate the complexity for the 99% use cases.