Retrieve library ELM XML from CQLTranslator

We have a use-case where we translate CQL queries to ELM XML programmatically. This is being done via the CqlTranslator class, which has factory methods that take input streams, strings, and files. We can then invoke the toXml method to obtain the ELM AST that we then use to run the CQL query. This works for queries that are entirely self-contained, but the XML returned does not contain the ELM for libraries referenced by the query. This ELM is necessary for us to compile the query in its entirety.

The necessary information seems to be present in the LibraryManager class, specifically the private libraries field. Libraries can be located via the resolveLibrary method on LibraryManager but this method requires that the caller be searching for a particular library. Additionally, the fact that it takes a list of CqlTranslatorException suggests to me that this may not be intended to be called by external users, but rather used in internal translation.

Would you consider adding/merging a PR to add a method on CqlTranslator like

public getLibrariesXmlById <String, String>(){

}

where the keys would be the library ID and the values would be the ELM XML for the corresponding libraries?

I think something like this could be accomplished at a user level by walking the AST and finding all libraries that need to be looked up, but this seems like unnecessary complication and still seems potentially problematic if resolveLibrary isn’t intended to be called by users. For an implementor, the cleanest architecture seems to me to be to segregate the translation into an AST into its own component and have the rest of the implementation work purely in terms of this AST, regardless of how that AST was generated.

Alternatively, is there something I’m missing about the API and the reasoning behind it? Perhaps there is a way to accomplish these goals already that I’m missing.

[brynrhodes]

Adressed in 1.3.14

[WilliamParker]

That should work for us @brynrhodes, thanks. We may not have time to create a PR in December but hopefully we can get to it in the near future if it isn’t otherwise addressed first.

cc @bdrillard