As above. We are transferring some content (JSON that will be stored as a string) into AEM as we're looking for ideas. This JSON data will be used as a datasource for AEM pages.
Here's what we've come up so far:
your thoughts? Thank you.
edit1:
Solved! Go to Solution.
Views
Replies
Total Likes
Thanks.
So if I understand you correctly, you want to provide the "id" of the node you need to lookup data from as a suffix.
In that case you should be able to deduce from the suffix itself the path of the data node in a performant way. I do not recommend to make a query for it, especially if it's possible to build a path directly from it.
For example:
String DATA_ROOT = "/var/datanodes/"; String suffix = ... // extract the suffix from the path; // Sanitize the suffix so it cannot be used to traverse to any location in the repo Resource dataResource = resourceResolver.getResource(DATA_ROOT + suffix);
(That's the simple way, if you want to provide multiple suffix values and not having any path elements in them, you have to have more sanitziing.)
This is a performant way to lookup the data nodes. In every case you will use the node names as an id, and you can build the paths very easily. In the best way to have all your data nodes in a single structure (as siblings using oak:unstructured nodes); while this makes using CRX/DE unusable, it's not a problem from an API point of view (and as long as you are able to avoid any traversal of all these sibling nodes).
HI @jayv25585659,
Other than above mentioned way, we can have lots of other way as well like, since this will be used as datastore for the page you can use acs genericlist for the same to store all 50k data easily. when needed use your code to traverse it.
One more solution will be store the .json file somewhere in the repo. like in dam then read and the file thru code and provide the data where ever it is needed.
Or convert the json into .excel and store it somewhere specailly in DAM and read it with the help of APache PIO library .
File storage will be a good way in my view.
Hope this will help.
Umesh Thakur
Thanks. I'll check out those 2.
What do you mean with "datasource for pages"? Is this is product information system usecase or something similar?
Generally, the the structure by a multitude of parameters. While access control doesn't sound like a important one in this case, I wonder about the access pattern. Do you need to have random access to each of these 50k nodes or are they always handled all in one iteration? In case of random access do you look them up by a fixed "name" (a path? Are there duplicates?) or do you need to search by some value within these nodes? Does ordering matter? How often do you update? Do you need to handle duplicat
In the end it's always a matter of priorities: Is a performant lookup by the system important? Or is it more important that you can navigate them by CRX/DE?
If navigating with CRX/DE is important, you should try to limit yourself to ~500 nodes folder. If you choose to store them as "oak:unstructured" you loose ordering but gain performance when adding/removing nodes.
I've edited my original question hoping it should give better context to my question. Thank you.
Thanks.
So if I understand you correctly, you want to provide the "id" of the node you need to lookup data from as a suffix.
In that case you should be able to deduce from the suffix itself the path of the data node in a performant way. I do not recommend to make a query for it, especially if it's possible to build a path directly from it.
For example:
String DATA_ROOT = "/var/datanodes/"; String suffix = ... // extract the suffix from the path; // Sanitize the suffix so it cannot be used to traverse to any location in the repo Resource dataResource = resourceResolver.getResource(DATA_ROOT + suffix);
(That's the simple way, if you want to provide multiple suffix values and not having any path elements in them, you have to have more sanitziing.)
This is a performant way to lookup the data nodes. In every case you will use the node names as an id, and you can build the paths very easily. In the best way to have all your data nodes in a single structure (as siblings using oak:unstructured nodes); while this makes using CRX/DE unusable, it's not a problem from an API point of view (and as long as you are able to avoid any traversal of all these sibling nodes).
Views
Likes
Replies
Views
Likes
Replies