gitmotte
gitmotte
> java.lang.AssertionError: [ValidationError [ > statement=alter table if exists public.table2 rename to table3; > capability=parsing > errors=[ParseException: Cannot parse statement: Encountered unexpected token: "exists" "EXISTS" > at line 1, column...
Usage-Documentation and to get an idea why the validation feature was designed this way (using the visitor pattern): https://github.com/JSQLParser/JSqlParser/wiki/Examples-of-SQL-Validation The idea to use annotations may be good, but it does...
> without that validation true fallback What kind of true fallback do you mean? Validation returns a list of ValidationErrors, if there are no errors placed by the ValidationCapability's, the...
> Every new feature will be reflected in the `toString()`. It is the best maintained part aside the Grammar itself. This is by the way not a very good practice...
> > What kind of true fallback do you mean? > > I assume, it refers to the fact that everything returns `VALID` unless it has been implemented explicitly. Like...
>> @gitmotte Are you simply saying, that using `toString` for this SQL construction is wrong? I am following your argument. However, I would not go as far as to put...
> The arguments look dogmatic too me. I still do not understand an actual improvement from that Design Patterns for JSQLParser specifically. > > > But I can see the...
It's about the definition of Feature's and FeatureSetValidation (Version, DatabaseType). Only new features need an implementation within the Validator-classes. A new RDBMS to be validated only needs the definition of...
I think it's @wumpz decision if the feature stays part of the library or not. Every single maintainer is called to complete all features when adding SQL constructs. Like the...