Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fluent builder api #1004 #1014

Merged
merged 67 commits into from
Aug 23, 2020
Merged

Fluent builder api #1004 #1014

merged 67 commits into from
Aug 23, 2020

Conversation

gitmotte
Copy link
Contributor

@gitmotte gitmotte commented Jul 9, 2020

#1004

except for the create methods all changes are committed.

  • chaining - methods returning "this" white_check_mark But leave the original ones intact. In fact setters should not return anything, so I would prefer the with way.
  • overwrite chaining - methods of abstract parents/interfaces for returning concrete type white_check_mark
  • add methods on collection-fields with varargs-parameter white_check_mark
  • add public T get(Class) - casting and returning an inner interface-type

Further the chaining api is used

  • within the parser (where reasonable)
  • within some testcases by manually creating the model, comparing the parsed model against the created one, comparing the deparsed created model with the statement which is parsed
  • within ReflectionModelTest to check consistency of model (added some empty constructors to the model if fields are not final)

gitmotte added 30 commits June 29, 2020 14:24
* create(...) methods
* chaining - methods returning "this"
* overwrite chaining - methods of abstract parents/interfaces for
returning concrete type
* add<Name> methods on collection-fields with varargs-parameter
* add public T get<Name>(Class<T>) - casting and returning an inner
interface-type
* add<Name> methods on collection-fields with collection-parameter

JSQLParser#1004
* add<Name> methods on collection-fields with varargs-parameter
* add<Name> methods on collection-fields with collection-parameter

JSQLParser#1004
* add some constructors
* fix and add "with" / "add" methods
* add some constructors
}

@Override()
public CreateFunction addFunctionDeclarationParts(String... functionDeclarationParts) {
Copy link
Contributor

@AnEmortalKid AnEmortalKid Jul 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we're just using super does it make sense to override? Ah I guess this might be because we want it to return the specific type and not AnythingThat extends CreateFunctionStatement

Copy link
Contributor Author

@gitmotte gitmotte Jul 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, because it will be casted to CreateFunction, the parent returns CreateFunctionalStatement - the effect is, that the order of chaining does not matter, otherwise it would matter and the methods returning the parent or the super-class of the parent needs to be called at last in a chaining-context.

expressions.add(new JdbcParameter());

execute.withName(name)
.withExecType(EXEC_TYPE.EXEC).withParenthesis(true)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

super nit we probably should have kept EXEC_TYPE.EXECUTE just so the assertion didn't change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@wumpz wumpz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a huge pull request. +1
You should not change existing tests. For instance you replaced the "old" variant of getting some parameter with the new, but both should be tested.

}
}
}
/*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this file completely replaced? Are there some kind of linefeed differences?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

324ccf1
tried to replace formatchanges, that compare finds matching lines

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0d434b8
seems that the original commit had different linefeeds than the other files in this project

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I',m sorry, did't work for this diff-view

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that was me. I work on a Mac and on a windows device from time to time. I’ll double check that we have a gitatttrbutes setup correctly to avoid these issues!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately only the latest versions of jgit, if you are using this, are taking gitattributes into account. But that explains this. If the file was wrong, now it would be corrected. So all fine.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AH, I use intellij, so i bet my Windows gitbash auto-core config crap wasn't setup right.

super("FUNCTION", functionDeclarationParts);
}

@Override()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you remove this brackets on a simple override?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, 9865783

@Test
public void testAlterOnlyIssue928() throws JSQLParserException {
assertSqlCanBeParsedAndDeparsed("ALTER TABLE ONLY categories ADD CONSTRAINT pk_categories PRIMARY KEY (category_id)");
String statement = "ALTER TABLE ONLY categories ADD CONSTRAINT pk_categories PRIMARY KEY (category_id)";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't replace existing tests. Create new tests.

Copy link
Contributor Author

@gitmotte gitmotte Jul 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

normally I would agree to the principle of not changing tests, but didn't change the assert, but extending it with additional asserts.
doesn't it make sense to check parsing/deparsing, creation of the model and comparing it against the parsed model all together?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But for instance you changed on various places the getExpression() to getExpression(Classtype).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the rest you wrote I agree.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getExpression(Classtype) calls getExpression() inside. I changed it if explicit casting was done within testcase.

@@ -52,6 +89,13 @@ public void testMultiPartTableNameWithServerNameAndDatabaseNameAndSchemaName() t
final String statement = "SELECT columnName FROM [server-name\\server-instance].databaseName.schemaName.tableName";
assertSqlCanBeParsedAndDeparsed(statement, false,
parser -> parser.withSquareBracketQuotation(true));
assertDeparse(new Select().withSelectBody(new PlainSelect()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't change existing tests in this way. Create new tests.

Copy link
Contributor Author

@gitmotte gitmotte Jul 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please have a look to the comment above at AlterTest.java


executeDeParser.deParse(execute);

String actual = buffer.toString();
assertTrue(actual.matches("EXECUTE " + name + " .*?, .*"));
assertEquals("EXEC " + name + " (?, ?)", actual);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here the outcome is suddenly EXEC not EXECUTE. Why?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reverted it to be EXEC - see #1014 (comment) too

@gitmotte gitmotte requested a review from wumpz July 15, 2020 15:02
Copy link
Member

@wumpz wumpz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far it looks good.

@wumpz
Copy link
Member

wumpz commented Jul 15, 2020

As always I merge using squash and merge for multi commit pull requests. If you want to squash it yourself, you are free to do so. One commit pull requests are merged normally.

@gitmotte
Copy link
Contributor Author

gitmotte commented Jul 15, 2020

No objections if you want to sqash into one commit. The summary in the first comment of this merge request would be an appropriate comment for this commit.
Thanks in advance!

@gitmotte
Copy link
Contributor Author

No objections if you want to sqash into one commit. The summary in the first comment of this merge request would be an appropriate comment for this commit.
Thanks in advance!

@wumpz it's ready to merge!

@wumpz
Copy link
Member

wumpz commented Jul 20, 2020

Sorry. I am out of business for some days. Will merge if I am back

@wumpz
Copy link
Member

wumpz commented Aug 9, 2020

So back on business. After I merged some other PRs you have some conflicts here. Please resolve those first. After this, I will merge. This PR was so far mergeable, right? Or do you want to add anything more?

@gitmotte
Copy link
Contributor Author

ok, i'v resolved the conflicts, it's ready to merge again. thanks in advance.

@gitmotte
Copy link
Contributor Author

@wumpz

@wumpz wumpz merged commit 6cff161 into JSQLParser:master Aug 23, 2020
@wumpz
Copy link
Member

wumpz commented Aug 23, 2020

I am sorry, it took a while. I will change the version number to reflect this large change.

@gitmotte gitmotte deleted the master.fluent branch August 26, 2020 08:24
mo3000 pushed a commit to mo3000/JSqlParser that referenced this pull request Aug 30, 2020
* JSQLParser#1004

* create(...) methods
* chaining - methods returning "this"
* overwrite chaining - methods of abstract parents/interfaces for
returning concrete type
* add<Name> methods on collection-fields with varargs-parameter
* add public T get<Name>(Class<T>) - casting and returning an inner
interface-type

* 1004 add chaining - methods returning "this"

* JSQLParser#1004 add chaining - methods returning "this"

* * add<Name> methods on collection-fields with varargs-parameter
* add<Name> methods on collection-fields with collection-parameter

JSQLParser#1004

* * add chaining - methods returning "this"
* add<Name> methods on collection-fields with varargs-parameter
* add<Name> methods on collection-fields with collection-parameter

JSQLParser#1004

* * add public T get<Name>(Class<T>) - casting and returning the concrete
type

JSQLParser#1004

* * add public T get<Name>(Class<T>) - casting and returning the concrete
type (swap Class<? extends E> for Class<E>)

JSQLParser#1004

* * overwrite chaining - methods of abstract parents/interfaces for
returning concrete type

JSQLParser#1004

* * add with prefix for fluent setters.

 JSQLParser#1004

* add getters

* * add with prefix for fluent setters. (revert to chaining setters, do
not break current api)

 JSQLParser#1004

* * add with prefix for fluent setters. (revert to chaining setters, do
not break current api)

 JSQLParser#1004

* use new methods within testcases

* use new methods within testcases

* use new methods within testcases

* use new methods within testcases

* use new methods within testcases

* use new methods within testcases

* use new methods within testcases

* use new methods within testcases

* remove create() methods - they do not add enough value to be justified

* * use new methods within testcases
* add some constructors
* fix and add "with" / "add" methods

* * use new methods within testcases

* * use new methods within testcases
* add some constructors

* * renamed constant

* use new methods within testcases

* use new methods within testcases

* use new methods within testcases

* use new methods within testcases

* * use new methods within testcases
* add some with-methods
* add getter/setter named after the field without abbrivation

* * use new methods within testcases

* remove empty implicit constructor

* return the deparsed Statement - object

* compare object tree

* compare object tree

* * fix ObjectTreeToStringStyle
* compare object tree

* remove casts not needed

* * use new methods within testcases
* add some "set" "with" "add" methods missing

* * use new methods within testcases

* add empty constructors and override with-/add-methods returning concrete
type

* * add ReflectionModelTest

* * use new methods within testcases

* fix checkstyle errors

* license header

* remove test-classes from ReflectionModelTest

* remove visitoradapter-classes from ReflectionModelTest

* remove duplicate import declaration (checkstyle error)

* * fix RandomUtils to support used java.sql.* types
* fix RandomUtils to support enums
* fix RandomUtils to map objects by its interfaces and super-classes
* filter method "setASTNode" - do not test setters (cannot randomly
create a SimpleNode)

* add javadoc, stating that this is a marker interface

JSQLParser#1014 (comment)

* revert formatting change
JSQLParser#1014 (comment)

* change to EXEC_TYPE.EXECUTE just so the assertion didn't change
JSQLParser#1014 (comment)

* try to revert format changes
JSQLParser#1014 (comment)

* try to revert format changes
JSQLParser#1014 (comment)

* remove brackets on @OverRide() -> @OverRide

* add with-methods to new fields
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants