GeezerVison is showing github.com — [FEATURE] missing feature description START WITH NN in ORACLE throws a JSQLParserException · Issue #1791 · JSQLParser/JSqlParser
[FEATURE] missing feature description START WITH NN in ORACLE throws a JSQLParserException #1791DescriptionThe START WITH NN in ORACLE is not supported.
I mean JsqlParser cannot parse an Oracle Table that has a START WITH NN.
(Don't know if this is a feature request or a bug).
For example; this table is not parsable:
-- location
CREATE TABLE locations
(
location_id NUMBER GENERATED BY DEFAULT AS IDENTITY START WITH 24
PRIMARY KEY ,
address VARCHAR2( 255 ) NOT NULL,
postal_code VARCHAR2( 20 ) ,
city VARCHAR2( 50 ) ,
state VARCHAR2( 50 ) ,
country_id CHAR( 2 ) , -- fk
CONSTRAINT fk_locations_countries
FOREIGN KEY( country_id )
REFERENCES countries( country_id )
ON DELETE CASCADE
);
It raises a JSQLParserException:
Encountered unexpected token: "START" "START"
If I remove START WITH 24 , the table is parsable.
Best,
N. Activitymanticore-projects commented on May 15, 2023 manticore-projects commented on May 15, 2023 Btw, if you want to test various statements and understand, why/where they fail then you can do this here and interactively
Based on the Grammar, I have no idea how GENERATED BY DEFAULT AS IDENTITY passes. But I will figure this out tomorrow. I assume it is just a chain of tokens (without any interpretation). manticore-projects commented on May 15, 2023 Ok, as expected the whole GENERATED BY DEFAULT AS IDENTITY START WITH 24 is not really parsed and interpreted but just taken as a chain of S_IDENTIFIER (which is a Token).
Since START is a Token also, it clashes (since in the chain, only words that are no tokens are allowed).
I will work around this by allowing certain non-reserved keywords and/or adding START to the CREATE PARAMETERS.
But you still will just get a list of tokens, not really an interpretation of their meaning. manticore-projects commented on May 15, 2023 ndepomereu commented on May 15, 2023 Hi,
Thanks, this is not urgent for me, I can get around it by suppressing the
START WITH NN.
Don't know if my input could interest you and your community, but maybe:
I provide a tool that works only on metadata, so I ask the users to import
their schema and I parse it.
My objective is to parse the schema with the least errors possible, of course.
The purpose is that my users see tables, columns, and primary keys only.
My goal is that they are no failures when importing their schema in my tool.
Failures that I don't anticipate are a pain because I must report, and
tell users they must hack their schema source before import...
I'm testing all majors databases with the most famous tutorial series for
MySQL, PostgreSQL, SQL Server, and Oracle.
For now, results with JSqlParser are very, very good.
The only 2 problems I met have been :
- Not supporting the:: in nextval with PostgreSQL.
- Not supporting the START WITH NN with Oracle database.
So, as I work on the metadata level, I'm able to discard the problems, while
keeping the base declaration, and my users don't even notice the problem.
Hope this helps.
Continue on the great work with JSQLParser!
Best,
Nicolas
Le lun. 15 mai 2023, 21:18, manticore-projects ***@***.***> a
écrit :
Nicolas de Pomereu
KawanSoft SAS
http://www.kawansoft.com
128, Rue La Boétie
75008 Paris - France
Tel: +33 (0)1 77 69 59 58
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|