List all images associated to a document

[mgerbaux]

The list of all images associated to a document should be available to be displayed more practically than through the slideshow tool (especially for documents with large collection of images like https://www.camptocamp.org/articles/1058594/fr/concours-photo-sophie-2018)

[cbeauchesne]

Links that should filters results (and don't) :

• https://www.camptocamp.org/images?c=1058594
• https://www.camptocamp.org/outings?c=700597

[asaunier]

The list of all images associated to a document should be available to be displayed more practically than through the slideshow tool (especially for documents with large collection of images like https://www.camptocamp.org/articles/1058594/fr/concours-photo-sophie-2018)

This description is not very relevant: the API has no slideshow tool.
Do you mean that the API should provide the full list of images associated to a given document?
For instance https://api.camptocamp.org/images?c=1058594 but without the paging limits (default is 30)?

At least it is possible to add a limit=100 parameter to the URL above, eg. https://api.camptocamp.org/images?c=1058594&limit=100
even tough there is a limit to the limit (100 ?).

I don't think it is a bug: it's a wanted limit to avoid returning too many items at once and load the API too much.

[cbeauchesne]

Agree that the bug classification is not so relevant, could be feature request.

Do you mean that the API should provide the full list of images associated to a given document

No, it must keep the limit/offset behavior, it's not a big deal for UI to implement a paged view, or an infinite scroll.

The issue is only about the /images?<document-type>=<document-id> entry point : it should returns images associated to <document-type>/<document-id>.

[asaunier]

@cbeauchesne Thanks for clarifying but

The issue is only about the /images?= entry point : it should returns images associated to /.

• Why is the document type relevant? Isn't the document_id sufficient?
• Do you mean that https://api.camptocamp.org/images?c=1058594 for instance is not returning the correct set of images (ie. associated to article 1058594)?

I think this ticket is confusing and does not describe clearly the problem, with the current situation and the expected one. Shouldn't it be reformulated?

[cbeauchesne]

Do you mean that https://api.camptocamp.org/images?c=1058594 for instance is not returning the correct set of images (ie. associated to article 1058594)?

Yes? Actually, c=1058594 is simply ignored.

Isn't the document_id sufficient?

Technicly, document_id is unique, whatever the document type. It means that all entry point that requires document type could have been written by omitting document type. But as far as I know, only history entry point does not specify document type : /document/56065/history/fr So, yes, document_id could sufficient. But, IMO, it would be preferable to stick to other entry point, and specify document type (e.g. c for this issue).

Shouldn't it be reformulated?

Yes :)

[momomaniac]

I manged to make this item work in #804
for the moment it is a test and only operational for
/images?o=xxx for outings
/images?c=xxx for articles

that questioned me on some points:

• is this feature really supposed to work ? (@cbeauchesne you marked it as bug) I could not find the code which should do the work
• has the syntax /images?c=xxx been decided / discussed somewhere
• I do not really like the syntax, I find it ambiguous. I would prefer something more explicit like /images?associated_to_id=xxx which would also be a single query parameter for all document types since the document_id is unique as said by asaunier
• shall it be possible to combine the query parameter with other search criteria, i.e date range, etc. ?

I would propose, I implement a simple solution with an identical query attribute for all document types (for example ?associated_to_id=xxx) and this attribute can be accesses form the routes for any document (/images, /routes, /articles, etc.)
Tell me what you think about the query parameter.

[cbeauchesne]

is this feature really supposed to work ? (@cbeauchesne you marked it as bug) I could not find the code which should do the work

It was working on V5, but it never worked on V6. So yes, we can see this as a faeture :)

has the syntax /images?c=xxx been decided / discussed somewhere

It sticks to the rest of the api :

• Get routes linked to a waypoint : https://api.camptocamp.org/routes?w=1202782
• Get outings linked to a waypoint : https://api.camptocamp.org/outings?w=1202782
• Get outings linked to a route : https://api.camptocamp.org/outings?r=57964
• etc ... there is no exceptions

I do not really like the syntax, I find it ambiguous. I would prefer something more explicit like /images?associated_to_id=xxx which would also be a single query parameter for all document types since the document_id is unique as said by asaunier

I agree, there is a design flaw IMO with this id. It's unique among all the DB, but we always have to deal with document types. And worse, there is two typology of document types (waypoint VS w, routes vs r, article vs b ...).
But, it will be an entire refactoring project to support a simplier API interface, and if you crawl the code, you'll see that it'll simplify it a lot, with lot of factorization. But for now, it's better to stay coherent, even with a design flaw.

shall it be possible to combine the query parameter with other search criteria, i.e date range, etc. ?

Sure ! But don't be too greedy ;)

[momomaniac]

Thanks for this detailed explanation. what happens is that the Elastic search index contains waypoints and routes for the category outing, but nothing (neither articles nor outings) for the category images. I think we should not add these fields into the ES index, it is just redundant data since the associations are contained in the DB. That's why a very simple and elegant solution would be to include a special attribute like associated_to_id which will bypass ES and query directly the DB for associations. This is very simple to code, but it cannot be combined with other ES search criteria. However, it seems like a very powerful feature to me, and no distinction is needed between the different document types (just sorting out who is parent and who is child) I will make a demo with this feature, and we can still decide on the full indexation.

…

On Tue, Apr 21, 2020 at 12:23 PM Charles de Beauchesne < ***@***.***> wrote: is this feature really supposed to work ? ***@***.*** <https://github.com/cbeauchesne> you marked it as bug) I could not find the code which should do the work It was working on V5, but it never worked on V6. So yes, we can see this as a faeture :) has the syntax /images?c=xxx been decided / discussed somewhere It sticks to the rest of the api : - Get routes linked to a waypoint : https://api.camptocamp.org/routes?w=1202782 - Get outings linked to a waypoint : https://api.camptocamp.org/outings?w=1202782 - Get outings linked to a route : https://api.camptocamp.org/outings?r=57964 - etc ... there is no exceptions I do not really like the syntax, I find it ambiguous. I would prefer something more explicit like /images?associated_to_id=xxx which would also be a single query parameter for all document types since the document_id is unique as said by asaunier I agree, there is a design flaw IMO with this id. It's unique among all the DB, *but* we always have to deal with document types. And worse, there is two typology of document types (waypoint VS w, routes vs r, article vs b ...). But, it will be an entire refactoring project to support a simplier API interface, and if you crawl the code, you'll see that it'll simplify it a lot, with lot of factorization. But for now, it's better to stay coherent, even with a design flaw. shall it be possible to combine the query parameter with other search criteria, i.e date range, etc. ? Sure ! But don't be too greedy ;) — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#751 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANY5RCUP6VIKZGM4CRO5HCTRNVXZ3ANCNFSM4IZ3XBOA> .

[cbeauchesne]

Actually, there is some entry point that use a common key, for instance : https://www.camptocamp.org/associations-history?d=1203070

But the point of using ES is to avoid access to DB. If the entry point is used a lot, it's better to use ES. But that's theory, as we do not have any visibility of actual charge, can't say if it's true for real 😞

Just, will it be not too complicated to handle both filtering : https://www.camptocamp.org/images?c=1058594&other_key_in_es=blabla ? If I understand well your message, you're saying /images entry point never use ES ?

[momomaniac]

But the point of using ES is to avoid access to DB. If the entry point is used a lot, it's better to use ES. But that's theory, as we do not have any visibility of actual charge, can't say if it's true for real 😞

Ok, thanks for the explanation

Just, will it be not too complicated to handle both filtering : https://www.camptocamp.org/images?c=1058594&other_key_in_es=blabla ? If I understand well your message, you're saying /images entry point never use ES ?

no, images uses ES, but image associations are not indexed in ES. Only some associations are actually indexed in ES (example waypoints, routes) Any association(ex: article -> images) which shall be searched via ES, must be added to the ES mapping. Adding all associations to ES sounds a bit crazy to me, it feels like a lot of redundant data. But actually I lack sufficient knowledge of ES to understand if adding associations would be a good idea. If additions are indexed in ES, it becomes easy to combine multicriteria search, sorting, etc. I'll try to find out more about ES scalability and performance...

…

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#751 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANY5RCV5CXMZKHHECUMQ7X3ROAGODANCNFSM4IZ3XBOA> .