I have some questions as to how the <include> tag should function.
First, how many <include> tags are allowed? The current online documentation states that the <setup> tag can have "a single nested include tag which specifies an external file containing the setup SQL to execute". However, the BNF listed as part of the <setup> tag syntax indicates that there can be zero or more include tags (which matches what the DTD indciates). I have used multiple <include> tags, but the documentation leads me to question which method is correct. (This question would also apply to the <teardown> tag.)
Second, since I use MS SQL Server 2000, is the keyword "GO" used as a delimiter (similar to a semi-colon), or is it used as a transaction boundary? (From the "SQLUnit Include Files" documentation: "The set of allowed delimiters are a free-standing slash ("/") character, a free-standing semicolon (";") character or a free-standing string "go" on its own line.")
Given the following T-SQL:
if exists (select *
from dbo.sysobjects
where ((id = object_id(N'SQLUnit_IncludeTagTestProc'))
and (OBJECTPROPERTY(id, N'IsProcedure') = 1))
)
begin
drop procedure SQLUnit_IncludeTagTestProc
end
go
create procedure SQLUnit_IncludeTagTestProc
(
@param1 integer output
)
as
begin
select @param1
end
go
If I attempt to use the above code within one include:
<include file="test/MyTestProc/SQLUnit_UseOnlyOneInclude.sql"/>
and attempt to "exec SQLUnit_IncludeTagTestProc" within the test case, then I receive errors indicating that the stored procedure does not exist.
However, if I split the above SQL into two .sql files, where each file contains only one GO, and then include them as:
The test executes without a problem. I am able to exec SQLUnit_IncludeTagTestProc.
In addition if I remove the "GO" from within the .sql file I receive the following error:
[sqlunit] sqlunit-ant: System error (net.sourceforge.sqlunit.parsers.ParseException): Encountered "<EOF>" at line 10, column 2.
[sqlunit] Was expecting one of:
[sqlunit] <MULTILINE_DELIMITER> ...
[sqlunit] <MULTILINE_CHAR> ...
[sqlunit]
This is the reason I ask if GO is being used as a delimiter or a transaction boundary: GO works without a problem if there is only one GO in the include file (i.e., each command is in a separate file), but does not appear to work if both statements are included as one file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
in my sqlunit tests I am using a smippet like this:
<setup>
<include file="test/mysql/delete.sql"/>
<include file="test/mysql/insert.sql"/>
</setup>
so <setup> definitely allows for then one <include> and it does executes both of them.
Unfortunately, I am not skillful enough in MS SQL server to give you any advice about it.
Regards
Ivan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The online documentation in the setup tag is incorrect. You can have as many include files in your setup and teardown tags as you need (zero or more).
There are no (conditional or otherwise) transactions around any of the statements separated by GO. This is not good, since the transaction-support attribute will determine the transactional properties of the Connection object, but since we dont consider the property here and issue conditional commit/rollbacks, this may lead to unexpected situations like you describe. There is some information about the different transaction-support modes in the "Controlling Transactions" in the online manual.
The only time there could be a mismatch is when transaction-support=on (default if unspecified), but I am a little surprised that you are seeing the problem since your setting is normally implicit. Is your setting implicit in this case?
I will put in the code to conditionally wrap these calls within transaction boundaries, so each of the statements within the GO will be in a transaction.
Removing the GO from the end of the file will result in the parsing error from JavaCC that you mention, since the parser is expecting to see a statement delimiter before it sees the end of file.
NOTE:
The above amounted to something of a wild goose chase, especially the part about the transactions, but since you are probably using implicit transactions, you this solution will not apply to your case. But my comments are valid and we should do the conditional wrapping of each statement as described above.
The problem was with the parsing. The parser is looking for \ngo\n so:
1) There can be no space after the go and the \n.
2) The last line in the file should always be empty (not strictly necessary since there is some code to check for this on EOF but good to do).
I have added your example in test/java/parsertest_syb.sql and a new test in IncludeFileParserTest#testWithSybaseFile() which exposed the problem.
I will put in the conditional commit/rollback code in the include handler based on the transaction-support property tomorrow and let you know.
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The IncludeHandler now respects the transactional properties of the connection. Here are the CVS logs for the check-in. Please check to see if the change in the file (removing the trailing space in the go) fixed the problem you encountered, and that these new changes do not affect you.
Checking in src/net/sourceforge/sqlunit/ConnectionRegistry.java;
/cvsroot/sqlunit/sqlunit/src/net/sourceforge/sqlunit/ConnectionRegistry.java,v <-- ConnectionRegistry.java
new revision: 1.22; previous revision: 1.21
done
Checking in src/net/sourceforge/sqlunit/handlers/CategoryHandler.java;
/cvsroot/sqlunit/sqlunit/src/net/sourceforge/sqlunit/handlers/CategoryHandler.java,v <-- CategoryHandler.java
new revision: 1.5; previous revision: 1.4
done
Checking in src/net/sourceforge/sqlunit/handlers/IncludeHandler.java;
/cvsroot/sqlunit/sqlunit/src/net/sourceforge/sqlunit/handlers/IncludeHandler.java,v <-- IncludeHandler.java
new revision: 1.11; previous revision: 1.10
done
Checking in test/java/parsertest_syb.sql;
/cvsroot/sqlunit/sqlunit/test/java/parsertest_syb.sql,v <-- parsertest_syb.sqlnew revision: 1.2; previous revision: 1.1
done
Checking in test/mock/groupingregexptest.xml;
/cvsroot/sqlunit/sqlunit/test/mock/groupingregexptest.xml,v <-- groupingregexptest.xml
new revision: 1.2; previous revision: 1.1
done
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My transaction-support attrbute was not "implicit". Once I added the attribute with that value the test passed with one or two <include> tags.
With respect to the parsing issue. I did run into something similar where the last \n is missing, and adjusted my .sql files before reporting the issue.
I pulled everything from CVS rebuilt and retested with success.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have some questions as to how the <include> tag should function.
First, how many <include> tags are allowed? The current online documentation states that the <setup> tag can have "a single nested include tag which specifies an external file containing the setup SQL to execute". However, the BNF listed as part of the <setup> tag syntax indicates that there can be zero or more include tags (which matches what the DTD indciates). I have used multiple <include> tags, but the documentation leads me to question which method is correct. (This question would also apply to the <teardown> tag.)
Second, since I use MS SQL Server 2000, is the keyword "GO" used as a delimiter (similar to a semi-colon), or is it used as a transaction boundary? (From the "SQLUnit Include Files" documentation: "The set of allowed delimiters are a free-standing slash ("/") character, a free-standing semicolon (";") character or a free-standing string "go" on its own line.")
Given the following T-SQL:
if exists (select *
from dbo.sysobjects
where ((id = object_id(N'SQLUnit_IncludeTagTestProc'))
and (OBJECTPROPERTY(id, N'IsProcedure') = 1))
)
begin
drop procedure SQLUnit_IncludeTagTestProc
end
go
create procedure SQLUnit_IncludeTagTestProc
(
@param1 integer output
)
as
begin
select @param1
end
go
If I attempt to use the above code within one include:
<include file="test/MyTestProc/SQLUnit_UseOnlyOneInclude.sql"/>
and attempt to "exec SQLUnit_IncludeTagTestProc" within the test case, then I receive errors indicating that the stored procedure does not exist.
However, if I split the above SQL into two .sql files, where each file contains only one GO, and then include them as:
<include file="test/MyTestProc/SQLUnit_CheckDropIncludeTagTestProc.sql"/>
<include file="test/MyTestProc/SQLUnit_IncludeTagTestProc.sql"/>
The test executes without a problem. I am able to exec SQLUnit_IncludeTagTestProc.
In addition if I remove the "GO" from within the .sql file I receive the following error:
[sqlunit] sqlunit-ant: System error (net.sourceforge.sqlunit.parsers.ParseException): Encountered "<EOF>" at line 10, column 2.
[sqlunit] Was expecting one of:
[sqlunit] <MULTILINE_DELIMITER> ...
[sqlunit] <MULTILINE_CHAR> ...
[sqlunit]
This is the reason I ask if GO is being used as a delimiter or a transaction boundary: GO works without a problem if there is only one GO in the include file (i.e., each command is in a separate file), but does not appear to work if both statements are included as one file.
Hello,
in my sqlunit tests I am using a smippet like this:
<setup>
<include file="test/mysql/delete.sql"/>
<include file="test/mysql/insert.sql"/>
</setup>
so <setup> definitely allows for then one <include> and it does executes both of them.
Unfortunately, I am not skillful enough in MS SQL server to give you any advice about it.
Regards
Ivan
Hi James,
The online documentation in the setup tag is incorrect. You can have as many include files in your setup and teardown tags as you need (zero or more).
There are no (conditional or otherwise) transactions around any of the statements separated by GO. This is not good, since the transaction-support attribute will determine the transactional properties of the Connection object, but since we dont consider the property here and issue conditional commit/rollbacks, this may lead to unexpected situations like you describe. There is some information about the different transaction-support modes in the "Controlling Transactions" in the online manual.
The only time there could be a mismatch is when transaction-support=on (default if unspecified), but I am a little surprised that you are seeing the problem since your setting is normally implicit. Is your setting implicit in this case?
I will put in the code to conditionally wrap these calls within transaction boundaries, so each of the statements within the GO will be in a transaction.
Removing the GO from the end of the file will result in the parsing error from JavaCC that you mention, since the parser is expecting to see a statement delimiter before it sees the end of file.
NOTE:
The above amounted to something of a wild goose chase, especially the part about the transactions, but since you are probably using implicit transactions, you this solution will not apply to your case. But my comments are valid and we should do the conditional wrapping of each statement as described above.
The problem was with the parsing. The parser is looking for \ngo\n so:
1) There can be no space after the go and the \n.
2) The last line in the file should always be empty (not strictly necessary since there is some code to check for this on EOF but good to do).
I have added your example in test/java/parsertest_syb.sql and a new test in IncludeFileParserTest#testWithSybaseFile() which exposed the problem.
I will put in the conditional commit/rollback code in the include handler based on the transaction-support property tomorrow and let you know.
-sujit
Hi James,
The IncludeHandler now respects the transactional properties of the connection. Here are the CVS logs for the check-in. Please check to see if the change in the file (removing the trailing space in the go) fixed the problem you encountered, and that these new changes do not affect you.
Checking in src/net/sourceforge/sqlunit/ConnectionRegistry.java;
/cvsroot/sqlunit/sqlunit/src/net/sourceforge/sqlunit/ConnectionRegistry.java,v <-- ConnectionRegistry.java
new revision: 1.22; previous revision: 1.21
done
Checking in src/net/sourceforge/sqlunit/handlers/CategoryHandler.java;
/cvsroot/sqlunit/sqlunit/src/net/sourceforge/sqlunit/handlers/CategoryHandler.java,v <-- CategoryHandler.java
new revision: 1.5; previous revision: 1.4
done
Checking in src/net/sourceforge/sqlunit/handlers/IncludeHandler.java;
/cvsroot/sqlunit/sqlunit/src/net/sourceforge/sqlunit/handlers/IncludeHandler.java,v <-- IncludeHandler.java
new revision: 1.11; previous revision: 1.10
done
Checking in test/java/parsertest_syb.sql;
/cvsroot/sqlunit/sqlunit/test/java/parsertest_syb.sql,v <-- parsertest_syb.sqlnew revision: 1.2; previous revision: 1.1
done
Checking in test/mock/groupingregexptest.xml;
/cvsroot/sqlunit/sqlunit/test/mock/groupingregexptest.xml,v <-- groupingregexptest.xml
new revision: 1.2; previous revision: 1.1
done
-sujit
Hi Sujit,
My transaction-support attrbute was not "implicit". Once I added the attribute with that value the test passed with one or two <include> tags.
With respect to the parsing issue. I did run into something similar where the last \n is missing, and adjusted my .sql files before reporting the issue.
I pulled everything from CVS rebuilt and retested with success.