Where to store lookup data in Adobe CQ

1
votes

For the past 3 years or so, we have been increasing our usage of Adobe CQ. We started out using 5.4 where several developers (on the recommendation of Adobe Consultants) stored several lookup "tables" of data in /var/site/app node. These were used as lookup stores for components such as ZIP codes, site IDs, etc.

Now we have ventured into CQ 5.6 and we are having some difficulty accessing this data on our publisher instance. The author works fine but when on the publisher,attempts to access the data result in a 404. A while back we had some other consultants mention that storing the data in /var was not a good idea but I don't recall the reasoning behind that.

Is there a recommended location for storing generic lookup data that several components, pages, or other objects will have access to?

Thanks in advance for your assistance.

3
aemjcrcrx
Thank you, all, for your replies. I will take this back to my team for further discussion. The data stored under /var does not change very often or at all and would not be maintained by editors. This question was posed to determine a general community best practice as the subject has sparked several debates. There is also the real concern that there is something behind the scenes going on in /var that could potential be disastrous and this we all want to avoid. – David Frey

3 Answers

2
votes

I am not an authority on the reasoning behind it, perhaps a person with vision to the decisions made along the way can step in, but from what I can tell, var was originally a location for any temporary or derived data, but not necessarily customer facing.

Versioning, and a stack of other information is stored there, so it should not be exposed to clients.

/etc is the location that has been left open on the dispatcher generally, so the logical place to put lookup info if it belongs as part of the SDLC, is within this location.

If the lookups were to be authorable, it would be more wise to place it in the /content directory, which if you're doing anything that involves multitenancy will fit in with the rewrite strategy. Furthermore, if different tenants are accessing the same lookup data, ie, 

http://www.mysite.com/mypage.html goes to /content/mysite/mypage and 
http://www.anothersite.com/anotherpage.html goes to /content/anothersite/anotherpage,

a rewrite rule can be used for the shared location. e.g.

www.mysite.com/lookups/postcodes.json /content/lookups/postcodes
www.anothersite.com/lookups/postcodes.json /content/lookups/postcodes

Hope that makes sense.

2
votes

I'm not sure this question is as simple as "where should you put it." How are your components/pages requesting this information? Is it via AJAX calls? If that's the case, you should really be accessing it through a Sling GET Servlet that produces the data as JSON. If you are talking about accessing this data via author instance dialogs, the location shouldn't matter, because generally your author instance is pretty open. If you are talking about accessing this data server-side, as part of component rendering (within the JSP or its backing Class), then you definitely don't need to move it anywhere, because the JcrResourceResolver has access to it.

I don't generally put anything under /var (it's a system part of the tree), but the solution isn't to pick another arbitrary location, just so you can expose it. The solution is to understand where you need to access that information and then expose it appropriately for that case. Make sense?

I'd be happy to provide more input if you could provide more detail about how you're trying to retrieve the data.

1
votes

/etc is a good place to store generic data that is separate from the display parts of CQ. For example CQ uses /etc/blueprints to store information about what is using LiveCopy. Author and publisher both have an /etc location so that isn't a problem. CQ can do funny things to /var so I'm not sure why it was recommended as a storage location.