ParseException: Cannot parse statement: Encountered unexpected token: "exists" "EXISTS"

[AmitAmely]

trafficstars

My code:

	@Test
	public void testJSQParser()
	{
		String sql = "alter table if exists public.table2 rename to table3;";
		Validation validation = new Validation(List.of(DatabaseType.POSTGRESQL), sql);
		List<ValidationError> errors = validation.validate();
		Assert.assertTrue(errors.toString(), errors.isEmpty());
	}

Result:

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 16.

Was expecting one of:

    "ADD"
    "ALGORITHM"
    "ALTER"
    "CHANGE"
    "COMMENT"
    "DROP"
    "MODIFY"
    "RENAME"
]
]]

This statement is a valid PostgreSQL syntax.

[manticore-projects]

Possible not supported. The supported syntax is: http://217.160.215.75:8080/jsqlformatter/_static/railroad_diagram.xhtml#AlterExpression

PRs are very welcome.

[manticore-projects]

With JSQLParser 4.2 Snapshot from GIT this test case succeeds:

    @Test
    public void testAlterTableRenameTo() throws JSQLParserException {
        String sqlStr="ALTER TABLE IF EXISTS table_name RENAME TO new_table_name";
        assertSqlCanBeParsedAndDeparsed(sqlStr, true);
        ValidationTestAsserts.validateNoErrors(sqlStr, 1, DatabaseType.POSTGRESQL);
    }

Although this Validation will always succeed for any RDBMS because nobody is really maintaining it. You would probably need to address @gitmotte , the author of this feature for support.

Please verify and close the case.

[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 16.

The validation fails on parsing. Maybe the schema specification in the above statement is the problem?

capability=parsing

The validation feature is of course expandable when it comes to syntax validation for rdbms. For my purposes it was sufficient so far.

Additions are welcome!

[wumpz]

Validation itself is a very cool feature for JSqlParser, but unfortunately the PRs for new syntactic features nearly never adapt the validation framework. Somehow those new features should be mapped the the supporting databases. Is it possible to get the classes that have no corresponding validation part? If I remember right, the validation itself uses a visitor pattern as well, so would it be sufficient to work on empty body methods?

[manticore-projects]

Validation itself is a very cool feature for JSqlParser,

Agreed.

but unfortunately the PRs for new syntactic features nearly never adapt the validation framework.

Guilty, but there are two challenges here:

1. not everyone is using this Validator. In fact how wonder how many people DO use it.
2. it is not transparent how to maintain it and there is no documentation about it

Somehow those new features should be mapped the the supporting databases.

Agreed and I have been thinking about that:

1. In my opinion, the current implementation is very hard to maintain. Also it struggles from the fact, that Default seems to be True as my example show. Default False would be better because people would complain when testing and then we would activate on demand.
2. Instead I would like to suggest a kind of Spreadsheet with one Feature as per Row and one RDBMS as per Column, where we can flag each Cell with Boolean/False.
3. Alternatively we could maybe use Annotations like @SupportsMySQL directly at the Java methods, although I do not know how feasible this is. The big advantage was that maintenance would happen during the implementation of a Feature.

In my opinion. the Validation Rules need to be maintained as close to the SQL Grammar as possible and then the Validator Java Code would need to be auto-generated "somehow".

[gitmotte]

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 not cover all types of validation. I'm only using the FeaturesAllowed and DatabaseMetaDataValidation in my projects, therefore, the DatabaseType/Version validations are not maintained. They are mostly stubs currently because its very hard to implement validation for all the different database types and versions.

I think the visitor pattern is good for validation, because there is no need to change the model, it's independent from parsing and in theory it could be split away from the parsing framework. Using annotations does not guarantee that they are set for new features.

[AmitAmely]

My need was for a framework with which I can validate SQL scripts that are added to my company's code base as part of the version upgrade mechanism (using Flyway). Our product works with Oracle and PostgreSQL DBs. My intention was to have a unit test that does a static analysis on those scripts based on the unique grammar of each DB. That's how I got to JSqlParser. Unfortunately I see that this kind of use of this library is not common, and that is why the code responsible for the validation functionality was not maintained. Should I look for other solutions?

[manticore-projects]

based on the unique grammar of each DB.

The idea of JSQLParser is to manage all possible SQL syntax of various RDBMS in one Grammar definition.

Unfortunately I see that this kind of use of this library is not common

It is not uncommon, I myself would also have taken a slightly different approach, e. g. defining a) a set of RDBMS which shall be supported and then b) find a way to flag each production for compatibility with a specific RDBMS. But that is only my gut feeling, the chosen approach is great for a lot of other objectives.

and that is why the code responsible for the validation functionality was not maintained.

Why not volunteer and just add the Validator Rules for Oracle and Postgresql? Or set a bounty for other developers? The frame work is there already, all it needs is some fine-tuning now.

Should I look for other solutions?

It is always good to know about options, but I myself came quite late for the party and stayed simply because I did not find anything even remotely as good as JSQLParser. Although I found a few short comings it was not too difficult to dive into the code and fill in what I was interested in myself.

Why not give it a try starting with the RENAME oldName TO newname statement and amend the Validator so it will accept Oracle and reject Postgresql.

[manticore-projects]

Using annotations does not guarantee that they are set for new features.

Very true. There is no silver bullet solution.

[wumpz]

My need was for a framework with which I can validate SQL scripts that are added to my company's code base as part of the version upgrade mechanism (using Flyway). Our product works with Oracle and PostgreSQL DBs. My intention was to have a unit test that does static analysis on those scripts based on the unique grammar of each DB. That's how I got to JSqlParser. Unfortunately, I see that this kind of use of this library is not common, and that is why the code responsible for the validation functionality was not maintained. Should I look for other solutions?

You should get it right. The validation extension of JSqlParser is very new. So you cannot say it is not maintained. As @manticore-projects and @gitmotte already mentioned, this extension like JSqlParser itself is feature request driven. So the validation extension as well fits the needs so far and didn't need to be extended. But the implementation should grow with JSqlParser and this step is hard to achieve. This step I was referring to.

@manticore-projects: The annotation support is very tempting, but it should (@gitmotte) not be the only way to define validation rules. I am thinking about it and at the moment see no clear way how and where to put those annotations. The common case in JSqlParser is that one AST - class holds behaviour for multiple RDBMS. So the annotations have to somehow hold a predicate expression.

´´´java @SupportsMySql( if this condition fits or these fields are set with these specific value ranges ) ´´´

Without those expressions, the annotations have only a very limited use case. Unfortunately, JavaCC does not support annotations within the grammar file. It's a pity.

My thinking at the moment goes more in the direction to improve the testing framework, if one can name those five methods a framework :), and automatically run a validation after each assertParseAndDeparse without that validation true fallback and check for not recognized expressions (somehow). @gitmotte Is that last checking step possible? With this, we could assure, that the validation framework at least processes the "new" change. To ensure completeness I see no right way at the moment.

[manticore-projects]

So you cannot say it is not maintained.

To be fair, it was I who used that term first -- referring to fact, that I indeed largely ignore the Validation Framework when I implement new features.

@manticore-projects: The annotation support is very tempting, but it should (@gitmotte) not be the only way to define validation rules.

I brought it up as an example only. In my opinion, the only chance to maintain the Validation Framework reliably is "as close as possible to the feature implementation".

My thinking at the moment goes more in the direction to improve the testing framework,

Could we not use the Annotations within the toString() methods. We compose the SQL syntax there wit all its elements and so are able to flag the compatibility.

Every new feature will be reflected in the toString(). It is the best maintained part aside the Grammar itself.

[wumpz]

As far as I know you cannot annotate parts of expressions within java. You can within the toString method only annotate types. The complete list of annotateable things is I think this:

• ElementType.ANNOTATION_TYPE
• ElementType.CONSTRUCTOR
• ElementType.FIELD
• ElementType.LOCAL_VARIABLE
• ElementType.METHOD
• ElementType.PACKAGE
• ElementType.PARAMETER
• ElementType.TYPE
• ElementType.TYPE_PARAMETER
• ElementType.TYPE_USE

So how should an annotated toString method look like? Or do you want to annotate the toString method itself?

[gitmotte]

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 validation is successful.

[gitmotte]

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 using the toString() method for construction of SQL - snippets. I know many model-classes use toString() for this task, but my opinion is there should be no logic within the model, it should be a POJO. Not for nothing was the deparser also designed with the visitor - pattern; unfortunately not consistently.

[manticore-projects]

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 the example above which is supposed to fail on Oracle. Instead, everything should FAIL unless it has been implemented explicitly and supported by a test.

This is by the way not a very good practice using the toString() method for construction of SQL - snippets. I know many model-classes use toString() for this task, but my opinion is there should be no logic within the model, it should be a POJO. Not for nothing was the deparser also designed with the visitor - pattern; unfortunately not consistently.

I am an accountant and have zero clue about software design and programing. Also I do not want to derail this thread even further. At the same time I hope you will appreciate a friendly sparring:

This is by the way not a very good practice using the toString() my opinion is there should be no logic within the model it should be a POJO

Please, why exactly? It keeps things closely together at one place, is simple and efficient. It just works well for its particular problem. What are the practical advantages of this additional abstraction layer? Please give me a real life, actual example where it made things easier or more efficient for a programmer or an end-user.

Not for nothing was the deparser also designed with the visitor - pattern

Please, tell me about it.

unfortunately not consistently.

Although I fully agree on this one. We should use either the Deparser Methods or the toString(). The current code duplication is difficult to understand.

@wumpz: No offense or hard feelings please, I am genuinely interested in this objective discussion and will always put my best effort in following the development policy and guidelines.

[manticore-projects]

So how should an annotated toString method look like? If we can't use Java Annotations inside a method, then maybe we would need to introduce switch-methods

validFor( RDBMS('Oracle', '12') , RDBMS('MSSQL') , RDBMS('Postgres') ) validFor( RDBMS('Oracle', '11.2') )

The we can place these calls into the toString() method, like in the example for DROP TABLE IF EXISTS tableName :

    @Override
    public String toString() {
        // Explicitly supported by Oracle since 12 and other RDBMS
        validFor( RDBMS("ORACLE", "12"), RDBMS("MSSQL"), RDBMS("POSTGRES") );
                
        String sql = "DROP " + type + " ";
        
        if (ifExists) {
            invalidFor( RDBMS("ORACLE", "11.2") ); // Not supported in Oracle 11.2 and previous versions
            sql += "IF EXISTS ";
        }
        sql += name.toString();

        if (parameters != null && !parameters.isEmpty()) {
            invalidFor( RDBMS("MySQL") ); // Not supported in MySQL
            sql += " " + PlainSelect.getStringList(parameters);
        }

        return sql;
    }

To make that work, each Statement and Expression would have to hold a long compatibilityMask which is set by the validFor() and invalidFor() and can be accessed by the Validator framework. compatibilityMask == 0 means Invalid on every RDBMS (which should never happen of course). compatibilityMask == Long.MAX_VALUE means, Valid on every RDBMS.

Also, this compatibilityMask can be used in the Tree: Branches would just AND the values of their Nodes.

This might all be a very stupid idea, but I myself would be able to make it work this way. And I see how I would be able to maintain it reliably and continuously in real life: Whenever something changes, you just add/change the validFor and invalidFor calls of the Statement and Expression.

Or do you want to annotate the toString method itself?

That would work only when we introduce many sub-methods for any IF ELSE block.

[gitmotte]

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 the example above which is supposed to fail on Oracle. Instead, everything should FAIL unless it has been implemented explicitly and supported by a test.

This is by the way not a very good practice using the toString() method for construction of SQL - snippets. I know many model-classes use toString() for this task, but my opinion is there should be no logic within the model, it should be a POJO. Not for nothing was the deparser also designed with the visitor - pattern; unfortunately not consistently.

I am an accountant and have zero clue about software design and programing. Also I do not want to derail this thread even further. At the same time I hope you will appreciate a friendly sparring:

This is by the way not a very good practice using the toString() my opinion is there should be no logic within the model it should be a POJO

Please, why exactly? It keeps things closely together at one place, is simple and efficient. It just works well for its particular problem. What are the practical advantages of this additional abstraction layer? Please give me a real life, actual example where it made things easier or more efficient for a programmer or an end-user.

Not for nothing was the deparser also designed with the visitor - pattern

Please, tell me about it.

unfortunately not consistently.

Although I fully agree on this one. We should use either the Deparser Methods or the toString(). The current code duplication is difficult to understand. .

The problem is that you cannot return false as default, because it is a fact that validations are never complete.

The visitor pattern is based on interfaces whose implementation is thus assured. However, if you provide an empty implementation, then nothing will be validated.

Regarding the toString() method - there are enough examples in the Java world where toString() was used across the board (i.e. BigDecimal.toString() became toPlainString() due to version change) and then became an upgrade issue. Furthermore, toString() is often emitted by loggers, which can lead to performance and privacy issues. It is simply that in the software architecture different layers are necessary to create a loose coupling that allows other usage.

[manticore-projects]

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 the example above which is supposed to fail on Oracle. Instead, everything should FAIL unless it has been implemented explicitly and supported by a test.

This is by the way not a very good practice using the toString() method for construction of SQL - snippets. I know many model-classes use toString() for this task, but my opinion is there should be no logic within the model, it should be a POJO. Not for nothing was the deparser also designed with the visitor - pattern; unfortunately not consistently.

I am an accountant and have zero clue about software design and programing. Also I do not want to derail this thread even further. At the same time I hope you will appreciate a friendly sparring:

This is by the way not a very good practice using the toString() my opinion is there should be no logic within the model it should be a POJO

Please, why exactly? It keeps things closely together at one place, is simple and efficient. It just works well for its particular problem. What are the practical advantages of this additional abstraction layer? Please give me a real life, actual example where it made things easier or more efficient for a programmer or an end-user.

Not for nothing was the deparser also designed with the visitor - pattern

Please, tell me about it.

unfortunately not consistently.

Although I fully agree on this one. We should use either the Deparser Methods or the toString(). The current code duplication is difficult to understand. .

The problem is that you cannot return false as default, because it is a fact that validations are never complete.

The visitor pattern is based on interfaces whose implementation is thus assured. However, if you provide an empty implementation, then nothing will be validated.

Regarding the toString() method - there are enough examples in the Java world where toString() was used across the board (i.e. BigDecimal.toString() became toPlainString() due to version change) and then became an upgrade issue. Furthermore, toString() is often emitted by loggers, which can lead to performance and privacy issues. It is simply that in the software architecture different layers are necessary to create a loose coupling that allows other usage.

I have a lot to respond to that but I do not want to make it look like an argument. Maybe we want to take that offline or move it into discussions? We share a mutual goal after all: implementing a robust, reliable and easily to maintain Validation framework.

[wumpz]

@wumpz: No offense or hard feelings please, I am genuinely interested in this objective discussion and will always put my best effort in following the development policy and guidelines.

No offense here. If a discussion brings a project forward then it is a good one. ( @manticore-projects but as we both unfortunately know, there are exceptions due to behavior :/ ) Again I don't see it as a code duplication but a test framework so to say. And my assumption was, that both (toString, deparser) have their merits while developing. Therefore I kept both.

validFor( RDBMS('Oracle', '12') , RDBMS('MSSQL') , RDBMS('Postgres') )

@manticore-projects @gitmotte Since the logic which expression and even subexpression can be executed on which database or even database version, toString will be (over)polluted. I would prefer the logic outside. I assume that's one of the reasons, the validation framework was developed outside the parse objects.

Regarding the toString() method - there are enough examples in the Java world where toString() was used across the board (i.e. BigDecimal.toString() became toPlainString() due to version change) and then became an upgrade issue. Furthermore, toString() is often emitted by loggers, which can lead to performance and privacy issues. It is simply that in the software architecture different layers are necessary to create a loose coupling that allows other usage.

@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 this SQL construction logic into a separate class. But I can see the positive effect of renaming toString to for instance toSql. Then everybody knows what to expect.

The problem is that you cannot return false as default, because it is a fact that validations are never complete.

@gitmotte But then how to force the developer to implement a validation or somehow push him smoothly in the right direction?

Not for nothing was the deparser also designed with the visitor - pattern; unfortunately not consistently.

That's in my opinion the same "validation" development problem. How to force somebody to implement the deparsing consistently? However, here we have the advantage that at least new syntactic features enforce interface changes and with that changes in the deparser.

[manticore-projects]

Again I don't see it as a code duplication but a test framework so to say. And my assumption was, that both (toString, deparser) have their merits while developing. Therefore I kept both.

And so be it. Someone needs to be in charge and define the policies.

toString will be (over)polluted.

Yes, maybe. But toString() is the only place where you understand the full logic at one place (e. g. what is a statement actually doing and what are all the possible variants). When I wrote JSQLFormatter, the toString() was the place to go to, especially for syntax and RDBMS I am not too familiar with. I was actually surprised how little SQL I know :-D Writing the Validator will have the same challenge: Defining rules for syntax you are not even aware of.

I would prefer the logic outside. I assume that's one of the reasons, the validation framework was developed outside the parse objects.

We have too many "separations" for my taste already, but ok, it is decided then.

@gitmotte Are you simply saying, that using toString for this SQL construction is wrong? I am following your argument.

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 positive effect of renaming toString to for instance toSql.

Or to StringBuilder appendTo(StringBuilder builder) maybe? :-D Joke aside: if we do not use toString() for composing the SQL, what shall toSting() return instead? I mean, after all toString() is supposed to give you the content of the Object -- what if not the SQL was that content please?

The problem is that you cannot return false as default, because it is a fact that validations are never complete.

@gitmotte But then how to force the developer to implement a validation or somehow push him smoothly in the right direction?

I strongly agree with @wumpz here: a false positive is much worse than a false negative. If a Validation fails because it has not been implemented then there is an incentive to report the issue and to amend the Validation. But if the Validation wrongly succeeds, then the information is wrong and potentially harmful. Compare it with a broken traffic light: would you rather see and endless RED or GREEN signal?

That's in my opinion the same "validation" development problem. How to force somebody to implement the deparsing consistently? However, here we have the advantage that at least new syntactic features enforce interface changes and with that changes in the deparser.

Exactly, the Deparser forces me to implement the features or else the Tests will fail or my Test Coverage would decline. Both would be rejected.

We should think about forcing the implementation of the Validation at least for 4 main RDBMS or else this Validation Tool will always fall behind.

[gitmotte]

@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 this SQL construction logic into a separate class. But I can see the positive effect of renaming toString to for instance toSql. Then everybody knows what to expect.

That would be much clearer, but it doesn't make the abstraction in context to the deparser any better. Personally, I don't like to rely on the stability of a toString() method. This often only technically expresses the content of an object, but not a formatted version of the content. To give an example, the strict separation of deparser and model (toString() or toSql()) would allow another implementation of a deparser using a special database syntax. I.e. the square brackets for object names at ms sql-server instead of quotes at other RDBMS.

The problem is that you cannot return false as default, because it is a fact that validations are never complete.

@gitmotte But then how to force the developer to implement a validation or somehow push him smoothly in the right direction?

I think this should happen with the interfaces implemented by visitor objects.

I know the visitor pattern is not very easy to understand, but it is wonderful for traversing an object tree.

Not for nothing was the deparser also designed with the visitor - pattern; unfortunately not consistently.

That's in my opinion the same "validation" development problem. How to force somebody to implement the deparsing consistently? However, here we have the advantage that at least new syntactic features enforce interface changes and with that changes in the deparser.

It's the same problem, yes. However, from my point of view, a customization consists of 4 steps.

• Adjustment of the parser
• Adaptation of the model (correct setter and getter, speaking names without abbreviations)
• Adaptation of the deparser-visitor objects + unit tests
• adaptation of validation (addition of feature names and corresponding validation) + unit tests

The enforcement of these 4 steps can only be done by the project manager, who reviews the addition of all parts before a merge and complains about missing adjustments.

[gitmotte]

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 positive effect of renaming toString to for instance toSql.

Or to StringBuilder appendTo(StringBuilder builder) maybe? :-D Joke aside: if we do not use toString() for composing the SQL, what shall toSting() return instead? I mean, after all toString() is supposed to give you the content of the Object -- what if not the SQL was that content please?

The output could be jdbc formatted sql with jdbc parameter placeholders. The current deparsers are only one implementation, there are several ways to format SQL, or to format database specific. With or without parameters, with named parameter placeholders or with jdbc-parameter placeholders. Also an implementation of a deparser, which translates into another language would be conceivable (i.e. HQL, JPQL, translate between RDBMS dialects, ...).

The problem is that you cannot return false as default, because it is a fact that validations are never complete.

@gitmotte But then how to force the developer to implement a validation or somehow push him smoothly in the right direction?

I strongly agree with @wumpz here: a false positive is much worse than a false negative. If a Validation fails because it has not been implemented then there is an incentive to report the issue and to amend the Validation. But if the Validation wrongly succeeds, then the information is wrong and potentially harmful. Compare it with a broken traffic light: would you rather see and endless RED or GREEN signal?

A traffic light is even a bit simple compared to a complex validation (which by the way does not only cover database syntax).

Unfortunately, I can't imagine how to check a "missing implementation", except through interfaces, because an implementation of a validation is never complete.

That's in my opinion the same "validation" development problem. How to force somebody to implement the deparsing consistently? However, here we have the advantage that at least new syntactic features enforce interface changes and with that changes in the deparser.

Exactly, the Deparser forces me to implement the features or else the Tests will fail or my Test Coverage would decline. Both would be rejected.

Testing the deparser is also far easier than testing a validation. Although there may be some formatting differences, it is essentially a string comparison without much logical background knowledge.

We should think about forcing the implementation of the Validation at least for 4 main RDBMS or else this Validation Tool will always fall behind.

That would be fine :)

[wumpz]

We should think about forcing the implementation of the Validation at least for 4 main RDBMS or else this Validation Tool will always fall behind.

+1

[gitmotte]

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 a new FeatureSet.

public enum DatabaseType implements FeatureSetValidation, Version {

    ANSI_SQL("ANSI SQL", SQLVersion.values()),
    // DBMS
    ORACLE(OracleVersion.values()),
    MYSQL(MySqlVersion.values()),
    SQLSERVER(SqlServerVersion.values()),
    MARIADB(MariaDbVersion.values()),
    POSTGRESQL(PostgresqlVersion.values()),
    H2(H2Version.values());

Personally I like the ANSI_SQL type the most, because it helps to write portable SQL, although this is not supported by all databases either.

[manticore-projects]

Since the Validation framework lacks a maintainer, who keeps up with the features and changes of the Parser I would like to recommend to split it off into its own project, maybe under a multi-project structure (similar JSQLFormatter).

I am closing this and recommend to continue under such a new umbrella.

[gitmotte]

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 "deparser", "validation" is also a feature that must be maintained.

A multi-project structure does not support better maintenance of the feature.

The Visitor pattern in general is not very easy to understand or implement. The design of this library dictates in some way to work with the model in this way.

I haven't looked at how your JSQLFormatter works - I assume this also needs a completion when new SQL constructs are added.