12:23 p.m.
[
https://issues.redhat.com/browse/TEIIDSB-170?page=com.atlassian.jira.plug...
]
Steven Hawkins edited comment on TEIIDSB-170 at 5/11/20 1:22 PM:
-----------------------------------------------------------------
Actually, this does not work, the scanning we are looking at is done
before the maven code-gen is run, so most of the techniques fall into the user's lap
to have the knowledge to enter these, thus failing the automation step.
I don't follow you on this. They simply are providing a materialization target (or
similar) unique name, which is used to drive the base names of the caches created.
I have started looking at yacc passed parser in GO to see if I can
write a parser for only the DDL statements that we need currently. Steven Hawkins can you
give examples of inline comments in SQL for these as you mentioned above? Looking through
SQL grammar file in Teiid, I find only one place like
I'm not looking forward to maintaining two parsers. I'd prefer most of the other
solutions to this one.
I was not sure any others exist?
End of line comments
{code} -- I'm a comment {code}
And inline/multi-line comments are supported - I even added comment nesting to further
complicate things.
{code}
/* I'm a big
comment
*/
{code}
{code}
/* I'm a big
comment
/* with a nested comment */
*/
{code}
was (Author: shawkins):
Actually, this does not work, the scanning we are looking at is done
before the maven code-gen is run, so most of the techniques fall into the user's lap
to have the knowledge to enter these, thus failing the automation step.
I don't follow you on this. They simply are providing a materialization target (or
similar) unique name, which is used to drive the base names of the caches created.
I have started looking at yacc passed parser in GO to see if I can
write a parser for only the DDL statements that we need currently. Steven Hawkins can you
give examples of inline comments in SQL for these as you mentioned above? Looking through
SQL grammar file in Teiid, I find only one place like
I'm not looking forward to maintaining two parsers. I'd prefer most of the other
solutions to this one.
I was not sure any others exist?
Multi-line comments are also supported - I even added comment nesting to further
complicate things.
Automate materialization to JDG
-------------------------------
Key: TEIIDSB-170
URL: https://issues.redhat.com/browse/TEIIDSB-170
Project: Teiid Spring Boot
Issue Type: Enhancement
Components: OpenShift
Reporter: Steven Hawkins
Assignee: Ramesh Reddy
Priority: Major
Fix For: 1.5.0
Original Estimate: 1 week
Time Spent: 1 week, 3 days, 2 hours
Remaining Estimate: 0 minutes
Create an internal materialization replacement needs that is turnkey materialization to
JDG (little to no user setup required)
- the operator may create the infinispan cluster if needed
- the status table and internal representation of the materialization target would be
setup automatically
For the user this would be as simple marking a view as materialized and then it would be
populated in jdg upon deployment. They would not have any concerns with cache naming,
status tables, etc.
For simplicity the initial version would make a similar assumption to the current
internal logic - it is for only a specific vdb. If the vdb cr is modified, then it's
expected that the cache would be recreated.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
1687
days inactive
1687
days old
0 comments
1 participants
participants (1)
-
Steven Hawkins (Jira)