Apache Cayenne support

[neopaf]

Friends, I'm fighting with lots of information in Apache Cayenne format. It has SQL templated.

Tried to hack a bit its support. Started with simple

#result('field' 'type' 'alias')

struct from https://cayenne.apache.org/docs/3.0/scripting-sqltemplate.html

Would appreciate any suggestions as to how to work around the fact that S_CHAR_LITERAL token already has apostrophe inside it.

[neopaf]

Came from here https://sourceforge.net/p/jailer/feature-requests/52/

[wumpz]

Don't you mixing up here SQL and Velocity template constructs? Sorry for asking.

[neopaf]

I am, in a way.

My idea was to quick-hack a way to analyse lots of (several megabytes) of SQL templates in that language.

I thought a quick way would be to alter JSqlParser to just add few constructs to its grammar.

But failed to fight my way trough https://javacc.org ideas. I guess this is exactly my case: http://www.engr.mun.ca/~theo/JavaCC-FAQ/javacc-faq-moz.htm#tth_sEc3.6

When token S_CHAR_LITERAL contains apostrophe and so does my feeble attempt -- see apostrophes in #result structure?

Maybe that is not the quick way after all. But I thought it would not hurt to ask.

Alternative: pre-process those SQL templates into SQL and only then apply JSQLParser.

[neopaf]

Cross-linking https://jira.apache.org/jira/browse/CAY-2495

[wumpz]

The best way to tackle this, would be to accept three S_CHAR_LITERALs.

#result('field' 'type' 'alias')

would be

<K_RESULT> "(" S_CHAR_LITERAL S_CHAR_LITERAL S_CHAR_LITERAL ")"

I see no problem here.

I do not know, where those constructs within a template SQL could be. The grammar adaption would be more difficult, I think, however not impossible.

[wumpz]

Nevertheless I would prefer the preprocess way, to not struggle with JSqlParser updates.

I would replace all constructs to a parsable identifier form. Maybe

 #result('field' 'type' 'alias')

to

__result___field____type____alias___

[neopaf]

I'm also inclining that way, but I love grammar definition languages and wanted to investigate that approach as well.

problem with S_CHAR_LITERAL is that it is NOT going to be handled properly later on.

that #result(field type alias) is in effect field as alias /type as a hint to template processor/

and if I go with suggested <K_RESULT> grammar, I would never get that literal looked into by SelectItem part of grammar :(

[manticore-projects]

Closing this as stale. Feel welcome to re-open when this was still relevant.