-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
-
Dose JSqlParser have plan to support Hive?
Beta Was this translation helpful? Give feedback.
All reactions
@manticore-projects I am not familiar with the HIVE QL, so the standard workflow fits in, which means that every feature request is evaluated if it could / should be included. A template at least at grammar level seems to be difficult, since still in pure javacc there are no "import" statements and alternatives that have "import" are ruled out for specific reasons.
Replies: 4 comments 2 replies
-
Greetings.
While I am only a contributor and can't speak on behalf of JSQLParser, I think we would be able to support HIVE fully when sponsored by an interested party.
Alternatively, Source Contributions and PR's would be welcome.
Beta Was this translation helpful? Give feedback.
All reactions
-
@kiddyu If I remember right, there already were Hive specific requests and implementations. JSqlParser is feature driven and not DBMS driven. So should not request for a specific database system but for specific syntactic constructs. So which special SQLs do you need to parse?
Beta Was this translation helpful? Give feedback.
All reactions
-
@wumpz: Since these questions come up quite frequently, I have checked out HIVE. Its not a SQL DB, but rather a "SQL alike" compatibility layer around Apache Hadoop.
While it resembles most ideas around SQL, it is as far from the SQL standard as JavaScript is from Java.
To me, it looks like it will need more than just amending a few productions in the Grammar and it would either be a "full HIVE support" thing or "No HIVE support" at all (except the few statements which are SQL compliant).
Maybe a template based JHiveParser on top of the JSQLParser framework...
Beta Was this translation helpful? Give feedback.
All reactions
-
@manticore-projects I am not familiar with the HIVE QL, so the standard workflow fits in, which means that every feature request is evaluated if it could / should be included. A template at least at grammar level seems to be difficult, since still in pure javacc there are no "import" statements and alternatives that have "import" are ruled out for specific reasons.
Beta Was this translation helpful? Give feedback.
All reactions
-
so the standard workflow fits in, which means that every feature request is evaluated if it could / should be included.
Greetings @wumpz.
Your assessment is correct, although (after looking a bit into the Hive SQL alike syntax), my concerns are:
-
We would need to add quite of a few productions not compatible/useful for any other RDBMS.
Look at theALTER TABLE ... ADD COLUMN...example: Hive implements the same semantic, just different syntax and so would likely need its own production for it. No idea, why they did that. -
We would introduce a lot more LOOKAHEADs, while we both observe and agree, that we need to avoid LOOKAHEAD as much as possible.
In my own opinion we would like to look into a more modular, object oriented design which:
a) uses Grammar Templates
b) from which a specific Grammar was derived for "Standard SQL and Friends", but also more obscure SQL dialects far away from standards (MySQL, Hive and other suspects)
c) generate an individual parser for each
Its just an idea, thinking out loud. It would be a lot of work and effort with no benefit for myself (because we do stick to Standard SQL).
Beta Was this translation helpful? Give feedback.
All reactions
-
Impression, beside KEYWORD related issues, "Hive support" is now the second often mentioned concern.
Beta Was this translation helpful? Give feedback.