[jira] [Commented] (DERBY-6913) Document the new ability of identity columns to cycle
[ https://issues.apache.org/jira/browse/DERBY-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549196#comment-15549196 ] Danoja Dias commented on DERBY-6913: We added some documentations for this feature in https://svn.apache.org/viewvc?view=revision&revision=1756297 Do we need to add another one? > Document the new ability of identity columns to cycle > - > > Key: DERBY-6913 > URL: https://issues.apache.org/jira/browse/DERBY-6913 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.13.1.0 >Reporter: Rick Hillegas > > We should document the cycling behavior before we release this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[ https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15446267#comment-15446267 ] Danoja Dias commented on DERBY-6852: I think now release note is more clear. I think now we can resolve this issue. > Allow identity columns to cycle (as defined in SQL:2003) > > > Key: DERBY-6852 > URL: https://issues.apache.org/jira/browse/DERBY-6852 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Peter Hansson >Assignee: Danoja Dias > Attachments: derby-6852_1.diff, derby6852doc.diff, derby_6852_2.diff, > derby_6852_3.diff, derby_6852_4.diff, failTests.diff, releaseNote.html, > releaseNote.html, script.sql > > > Currently when an IDENTITY column reaches its maximum value it will produce > an error. > For tables that are used as 'transaction logs' or 'event logs' it often makes > sense to let the table automatically start over with the first identity value > again when the max is reached. This would be similar to the CYCLE option on > Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used > quite often for this purpose, I guess, perhaps even more than other RDBMSs. > At the moment every developer have to program their own logic for this. > I propose to introduce the CYCLE option. > The idea of CYCLE is based on the assumption that there's been a prior > cleanup in the table rows so that it will be possible to re-use ids that have > been used previously. If that is not the case - and a rollover happens - then > a duplicate value error will occur. In this sense it can be argued that the > CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby > users would possibly gladly accept such a bargain. In other words: This > option will greatly enhance the usability of IDENTITY columns. > The current implementation of IDENTITY columns SQL grammar in Derby is a > subset of the SQL:2003 standard which is the first of the SQL standards to > define IDENTITY columns. Interestingly the standard also defines the CYCLE > option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003 > features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures] > (scroll to T174). > In other words: The proposal is simply to implement CYCLE as defined in > SQL:2003. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[ https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6852: --- Attachment: releaseNote.html I added the releaseNote.html . Should we make any more changes on that? > Allow identity columns to cycle (as defined in SQL:2003) > > > Key: DERBY-6852 > URL: https://issues.apache.org/jira/browse/DERBY-6852 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Peter Hansson >Assignee: Danoja Dias > Attachments: derby-6852_1.diff, derby6852doc.diff, derby_6852_2.diff, > derby_6852_3.diff, derby_6852_4.diff, failTests.diff, releaseNote.html, > script.sql > > > Currently when an IDENTITY column reaches its maximum value it will produce > an error. > For tables that are used as 'transaction logs' or 'event logs' it often makes > sense to let the table automatically start over with the first identity value > again when the max is reached. This would be similar to the CYCLE option on > Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used > quite often for this purpose, I guess, perhaps even more than other RDBMSs. > At the moment every developer have to program their own logic for this. > I propose to introduce the CYCLE option. > The idea of CYCLE is based on the assumption that there's been a prior > cleanup in the table rows so that it will be possible to re-use ids that have > been used previously. If that is not the case - and a rollover happens - then > a duplicate value error will occur. In this sense it can be argued that the > CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby > users would possibly gladly accept such a bargain. In other words: This > option will greatly enhance the usability of IDENTITY columns. > The current implementation of IDENTITY columns SQL grammar in Derby is a > subset of the SQL:2003 standard which is the first of the SQL standards to > define IDENTITY columns. Interestingly the standard also defines the CYCLE > option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003 > features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures] > (scroll to T174). > In other words: The proposal is simply to implement CYCLE as defined in > SQL:2003. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[ https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6852: --- Issue & fix info: Newcomer,Release Note Needed (was: Newcomer) > Allow identity columns to cycle (as defined in SQL:2003) > > > Key: DERBY-6852 > URL: https://issues.apache.org/jira/browse/DERBY-6852 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Peter Hansson >Assignee: Danoja Dias > Attachments: derby-6852_1.diff, derby6852doc.diff, derby_6852_2.diff, > derby_6852_3.diff, derby_6852_4.diff, failTests.diff, script.sql > > > Currently when an IDENTITY column reaches its maximum value it will produce > an error. > For tables that are used as 'transaction logs' or 'event logs' it often makes > sense to let the table automatically start over with the first identity value > again when the max is reached. This would be similar to the CYCLE option on > Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used > quite often for this purpose, I guess, perhaps even more than other RDBMSs. > At the moment every developer have to program their own logic for this. > I propose to introduce the CYCLE option. > The idea of CYCLE is based on the assumption that there's been a prior > cleanup in the table rows so that it will be possible to re-use ids that have > been used previously. If that is not the case - and a rollover happens - then > a duplicate value error will occur. In this sense it can be argued that the > CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby > users would possibly gladly accept such a bargain. In other words: This > option will greatly enhance the usability of IDENTITY columns. > The current implementation of IDENTITY columns SQL grammar in Derby is a > subset of the SQL:2003 standard which is the first of the SQL standards to > define IDENTITY columns. Interestingly the standard also defines the CYCLE > option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003 > features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures] > (scroll to T174). > In other words: The proposal is simply to implement CYCLE as defined in > SQL:2003. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[ https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420155#comment-15420155 ] Danoja Dias commented on DERBY-6852: I saw a release note added in DERBY-6209. I got some understanding on how the release note must be referring to that. Do we make Release notes using DITA or HTML? > Allow identity columns to cycle (as defined in SQL:2003) > > > Key: DERBY-6852 > URL: https://issues.apache.org/jira/browse/DERBY-6852 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Peter Hansson >Assignee: Danoja Dias > Attachments: derby-6852_1.diff, derby6852doc.diff, derby_6852_2.diff, > derby_6852_3.diff, derby_6852_4.diff, failTests.diff, script.sql > > > Currently when an IDENTITY column reaches its maximum value it will produce > an error. > For tables that are used as 'transaction logs' or 'event logs' it often makes > sense to let the table automatically start over with the first identity value > again when the max is reached. This would be similar to the CYCLE option on > Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used > quite often for this purpose, I guess, perhaps even more than other RDBMSs. > At the moment every developer have to program their own logic for this. > I propose to introduce the CYCLE option. > The idea of CYCLE is based on the assumption that there's been a prior > cleanup in the table rows so that it will be possible to re-use ids that have > been used previously. If that is not the case - and a rollover happens - then > a duplicate value error will occur. In this sense it can be argued that the > CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby > users would possibly gladly accept such a bargain. In other words: This > option will greatly enhance the usability of IDENTITY columns. > The current implementation of IDENTITY columns SQL grammar in Derby is a > subset of the SQL:2003 standard which is the first of the SQL standards to > define IDENTITY columns. Interestingly the standard also defines the CYCLE > option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003 > features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures] > (scroll to T174). > In other words: The proposal is simply to implement CYCLE as defined in > SQL:2003. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[ https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6852: --- Attachment: failTests.diff I added tests to test current alter table behavior and also to demonstrate the current values of sys.syscolumns and sys.syssequences when defining identity columsn both with and without the CYCLE option in failTests.diff. But the tests of sys.syscolumns and sys.syssequences fails with a message of junit.framework.AssertionFailedError: expected:but was: When I run these tests with ij tool it works fine. May be I am doing something wrong in writing the tests. > Allow identity columns to cycle (as defined in SQL:2003) > > > Key: DERBY-6852 > URL: https://issues.apache.org/jira/browse/DERBY-6852 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Peter Hansson >Assignee: Danoja Dias > Attachments: derby-6852_1.diff, derby6852doc.diff, derby_6852_2.diff, > derby_6852_3.diff, derby_6852_4.diff, failTests.diff, script.sql > > > Currently when an IDENTITY column reaches its maximum value it will produce > an error. > For tables that are used as 'transaction logs' or 'event logs' it often makes > sense to let the table automatically start over with the first identity value > again when the max is reached. This would be similar to the CYCLE option on > Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used > quite often for this purpose, I guess, perhaps even more than other RDBMSs. > At the moment every developer have to program their own logic for this. > I propose to introduce the CYCLE option. > The idea of CYCLE is based on the assumption that there's been a prior > cleanup in the table rows so that it will be possible to re-use ids that have > been used previously. If that is not the case - and a rollover happens - then > a duplicate value error will occur. In this sense it can be argued that the > CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby > users would possibly gladly accept such a bargain. In other words: This > option will greatly enhance the usability of IDENTITY columns. > The current implementation of IDENTITY columns SQL grammar in Derby is a > subset of the SQL:2003 standard which is the first of the SQL standards to > define IDENTITY columns. Interestingly the standard also defines the CYCLE > option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003 > features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures] > (scroll to T174). > In other words: The proposal is simply to implement CYCLE as defined in > SQL:2003. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[ https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419003#comment-15419003 ] Danoja Dias commented on DERBY-6852: I also think that it would be better to file new JIRA s for this issue. > Allow identity columns to cycle (as defined in SQL:2003) > > > Key: DERBY-6852 > URL: https://issues.apache.org/jira/browse/DERBY-6852 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Peter Hansson >Assignee: Danoja Dias > Attachments: derby-6852_1.diff, derby6852doc.diff, derby_6852_2.diff, > derby_6852_3.diff, derby_6852_4.diff, script.sql > > > Currently when an IDENTITY column reaches its maximum value it will produce > an error. > For tables that are used as 'transaction logs' or 'event logs' it often makes > sense to let the table automatically start over with the first identity value > again when the max is reached. This would be similar to the CYCLE option on > Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used > quite often for this purpose, I guess, perhaps even more than other RDBMSs. > At the moment every developer have to program their own logic for this. > I propose to introduce the CYCLE option. > The idea of CYCLE is based on the assumption that there's been a prior > cleanup in the table rows so that it will be possible to re-use ids that have > been used previously. If that is not the case - and a rollover happens - then > a duplicate value error will occur. In this sense it can be argued that the > CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby > users would possibly gladly accept such a bargain. In other words: This > option will greatly enhance the usability of IDENTITY columns. > The current implementation of IDENTITY columns SQL grammar in Derby is a > subset of the SQL:2003 standard which is the first of the SQL standards to > define IDENTITY columns. Interestingly the standard also defines the CYCLE > option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003 > features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures] > (scroll to T174). > In other words: The proposal is simply to implement CYCLE as defined in > SQL:2003. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[
https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15415525#comment-15415525
]
Danoja Dias commented on DERBY-6852:
{quote}
1) if column 'a' is 'generated always as identity (start with 2147483647
cycle)', and you issue:
alter table t alter column a set increment by 4
and then you insert some rows into the table, does it still correctly cycle?
2) if column 'a' is 'generated always as identity (increment by 2 cycle)', and
you issue:
alter table t alter column a restart with 2147483647
{quote}
I ran these two tests. But they do not succeed. After alter tale is done, cycle
option does not work any more. I am working on that now.
> Allow identity columns to cycle (as defined in SQL:2003)
>
>
> Key: DERBY-6852
> URL: https://issues.apache.org/jira/browse/DERBY-6852
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Reporter: Peter Hansson
>Assignee: Danoja Dias
> Attachments: derby-6852_1.diff, derby6852doc.diff, derby_6852_2.diff,
> derby_6852_3.diff, derby_6852_4.diff, script.sql
>
>
> Currently when an IDENTITY column reaches its maximum value it will produce
> an error.
> For tables that are used as 'transaction logs' or 'event logs' it often makes
> sense to let the table automatically start over with the first identity value
> again when the max is reached. This would be similar to the CYCLE option on
> Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used
> quite often for this purpose, I guess, perhaps even more than other RDBMSs.
> At the moment every developer have to program their own logic for this.
> I propose to introduce the CYCLE option.
> The idea of CYCLE is based on the assumption that there's been a prior
> cleanup in the table rows so that it will be possible to re-use ids that have
> been used previously. If that is not the case - and a rollover happens - then
> a duplicate value error will occur. In this sense it can be argued that the
> CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby
> users would possibly gladly accept such a bargain. In other words: This
> option will greatly enhance the usability of IDENTITY columns.
> The current implementation of IDENTITY columns SQL grammar in Derby is a
> subset of the SQL:2003 standard which is the first of the SQL standards to
> define IDENTITY columns. Interestingly the standard also defines the CYCLE
> option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003
> features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures]
> (scroll to T174).
> In other words: The proposal is simply to implement CYCLE as defined in
> SQL:2003.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[ https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15413595#comment-15413595 ] Danoja Dias commented on DERBY-6852: Yes. all tests are clean. > Allow identity columns to cycle (as defined in SQL:2003) > > > Key: DERBY-6852 > URL: https://issues.apache.org/jira/browse/DERBY-6852 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Peter Hansson >Assignee: Danoja Dias > Attachments: derby-6852_1.diff, derby6852doc.diff, derby_6852_2.diff, > derby_6852_3.diff, derby_6852_4.diff, script.sql > > > Currently when an IDENTITY column reaches its maximum value it will produce > an error. > For tables that are used as 'transaction logs' or 'event logs' it often makes > sense to let the table automatically start over with the first identity value > again when the max is reached. This would be similar to the CYCLE option on > Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used > quite often for this purpose, I guess, perhaps even more than other RDBMSs. > At the moment every developer have to program their own logic for this. > I propose to introduce the CYCLE option. > The idea of CYCLE is based on the assumption that there's been a prior > cleanup in the table rows so that it will be possible to re-use ids that have > been used previously. If that is not the case - and a rollover happens - then > a duplicate value error will occur. In this sense it can be argued that the > CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby > users would possibly gladly accept such a bargain. In other words: This > option will greatly enhance the usability of IDENTITY columns. > The current implementation of IDENTITY columns SQL grammar in Derby is a > subset of the SQL:2003 standard which is the first of the SQL standards to > define IDENTITY columns. Interestingly the standard also defines the CYCLE > option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003 > features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures] > (scroll to T174). > In other words: The proposal is simply to implement CYCLE as defined in > SQL:2003. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[ https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6852: --- Attachment: derby6852doc.diff I added derby6852doc.diff that changes the documentation. I changed the syntax of the identity column. This documentation does not use comma. It is the standard too. I think, we use comma, only for backward compatibility. > Allow identity columns to cycle (as defined in SQL:2003) > > > Key: DERBY-6852 > URL: https://issues.apache.org/jira/browse/DERBY-6852 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Peter Hansson >Assignee: Danoja Dias > Attachments: derby-6852_1.diff, derby6852doc.diff, derby_6852_2.diff, > derby_6852_3.diff, derby_6852_4.diff, script.sql > > > Currently when an IDENTITY column reaches its maximum value it will produce > an error. > For tables that are used as 'transaction logs' or 'event logs' it often makes > sense to let the table automatically start over with the first identity value > again when the max is reached. This would be similar to the CYCLE option on > Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used > quite often for this purpose, I guess, perhaps even more than other RDBMSs. > At the moment every developer have to program their own logic for this. > I propose to introduce the CYCLE option. > The idea of CYCLE is based on the assumption that there's been a prior > cleanup in the table rows so that it will be possible to re-use ids that have > been used previously. If that is not the case - and a rollover happens - then > a duplicate value error will occur. In this sense it can be argued that the > CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby > users would possibly gladly accept such a bargain. In other words: This > option will greatly enhance the usability of IDENTITY columns. > The current implementation of IDENTITY columns SQL grammar in Derby is a > subset of the SQL:2003 standard which is the first of the SQL standards to > define IDENTITY columns. Interestingly the standard also defines the CYCLE > option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003 > features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures] > (scroll to T174). > In other words: The proposal is simply to implement CYCLE as defined in > SQL:2003. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[ https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6852: --- Attachment: derby_6852_4.diff Hi Bryan, derby_6852_4.diff patch solves the problems that you pointed out. And also I have added new tests that you mentioned and my own new tests to IdentitySequenceTest.java. > Allow identity columns to cycle (as defined in SQL:2003) > > > Key: DERBY-6852 > URL: https://issues.apache.org/jira/browse/DERBY-6852 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Peter Hansson >Assignee: Danoja Dias > Attachments: derby-6852_1.diff, derby_6852_2.diff, derby_6852_3.diff, > derby_6852_4.diff, script.sql > > > Currently when an IDENTITY column reaches its maximum value it will produce > an error. > For tables that are used as 'transaction logs' or 'event logs' it often makes > sense to let the table automatically start over with the first identity value > again when the max is reached. This would be similar to the CYCLE option on > Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used > quite often for this purpose, I guess, perhaps even more than other RDBMSs. > At the moment every developer have to program their own logic for this. > I propose to introduce the CYCLE option. > The idea of CYCLE is based on the assumption that there's been a prior > cleanup in the table rows so that it will be possible to re-use ids that have > been used previously. If that is not the case - and a rollover happens - then > a duplicate value error will occur. In this sense it can be argued that the > CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby > users would possibly gladly accept such a bargain. In other words: This > option will greatly enhance the usability of IDENTITY columns. > The current implementation of IDENTITY columns SQL grammar in Derby is a > subset of the SQL:2003 standard which is the first of the SQL standards to > define IDENTITY columns. Interestingly the standard also defines the CYCLE > option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003 > features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures] > (scroll to T174). > In other words: The proposal is simply to implement CYCLE as defined in > SQL:2003. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[ https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6852: --- Attachment: derby_6852_3.diff derby_6852_3.diff supports cycle feature. This works whether there is comma or not. > Allow identity columns to cycle (as defined in SQL:2003) > > > Key: DERBY-6852 > URL: https://issues.apache.org/jira/browse/DERBY-6852 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Peter Hansson >Assignee: Danoja Dias > Attachments: derby-6852_1.diff, derby_6852_2.diff, derby_6852_3.diff, > script.sql > > > Currently when an IDENTITY column reaches its maximum value it will produce > an error. > For tables that are used as 'transaction logs' or 'event logs' it often makes > sense to let the table automatically start over with the first identity value > again when the max is reached. This would be similar to the CYCLE option on > Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used > quite often for this purpose, I guess, perhaps even more than other RDBMSs. > At the moment every developer have to program their own logic for this. > I propose to introduce the CYCLE option. > The idea of CYCLE is based on the assumption that there's been a prior > cleanup in the table rows so that it will be possible to re-use ids that have > been used previously. If that is not the case - and a rollover happens - then > a duplicate value error will occur. In this sense it can be argued that the > CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby > users would possibly gladly accept such a bargain. In other words: This > option will greatly enhance the usability of IDENTITY columns. > The current implementation of IDENTITY columns SQL grammar in Derby is a > subset of the SQL:2003 standard which is the first of the SQL standards to > define IDENTITY columns. Interestingly the standard also defines the CYCLE > option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003 > features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures] > (scroll to T174). > In other words: The proposal is simply to implement CYCLE as defined in > SQL:2003. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[ https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407008#comment-15407008 ] Danoja Dias commented on DERBY-853: --- I think, we can resolve this issue. > ResultSetMetaData.getScale returns inconsistent values for DOUBLE type. > --- > > Key: DERBY-853 > URL: https://issues.apache.org/jira/browse/DERBY-853 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Daniel John Debrunner >Assignee: Danoja Dias >Priority: Trivial > Labels: derby_triage10_5_2 > Attachments: BryanPossibleIdea.diff, Derby-853.diff, > Derby-853_2.diff, Derby-853_3.diff, Derby853.java > > > If a DOUBLE column is returned in the result set then getScale() returns 0. > If a DOUBLE expression is returned and the expression is the result of a > DOUBLE combined with a DECIMAL then it seems the scale from the decimal > sometimes affects the result set metadata. > E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2. > See the test output for jdbcapi/metadata.java > double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE > double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type > name: DOUBLE > dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type > name: DOUBLE > First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL - > DOUBLE > I assume the scale should always be zero for a DOUBLE, as it holds no > meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial > book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[ https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15406849#comment-15406849 ] Danoja Dias commented on DERBY-853: --- All test are clean in my system too. > ResultSetMetaData.getScale returns inconsistent values for DOUBLE type. > --- > > Key: DERBY-853 > URL: https://issues.apache.org/jira/browse/DERBY-853 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Daniel John Debrunner >Assignee: Danoja Dias >Priority: Trivial > Labels: derby_triage10_5_2 > Attachments: BryanPossibleIdea.diff, Derby-853.diff, > Derby-853_2.diff, Derby-853_3.diff, Derby853.java > > > If a DOUBLE column is returned in the result set then getScale() returns 0. > If a DOUBLE expression is returned and the expression is the result of a > DOUBLE combined with a DECIMAL then it seems the scale from the decimal > sometimes affects the result set metadata. > E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2. > See the test output for jdbcapi/metadata.java > double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE > double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type > name: DOUBLE > dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type > name: DOUBLE > First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL - > DOUBLE > I assume the scale should always be zero for a DOUBLE, as it holds no > meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial > book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[ https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405293#comment-15405293 ] Danoja Dias commented on DERBY-853: --- Hi Bryan, I think since scale of all other types(that are supported for operations like "-") should be 0, this is a simple and good approach. thanks. > ResultSetMetaData.getScale returns inconsistent values for DOUBLE type. > --- > > Key: DERBY-853 > URL: https://issues.apache.org/jira/browse/DERBY-853 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Daniel John Debrunner >Assignee: Danoja Dias >Priority: Trivial > Labels: derby_triage10_5_2 > Attachments: BryanPossibleIdea.diff, Derby-853.diff, > Derby-853_2.diff, Derby-853_3.diff, Derby853.java > > > If a DOUBLE column is returned in the result set then getScale() returns 0. > If a DOUBLE expression is returned and the expression is the result of a > DOUBLE combined with a DECIMAL then it seems the scale from the decimal > sometimes affects the result set metadata. > E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2. > See the test output for jdbcapi/metadata.java > double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE > double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type > name: DOUBLE > dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type > name: DOUBLE > First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL - > DOUBLE > I assume the scale should always be zero for a DOUBLE, as it holds no > meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial > book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[ https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-853: -- Attachment: Derby-853_3.diff This patch adds the tests to test this bug. This patch touches M java/engine/org/apache/derby/impl/sql/compile/NumericTypeCompiler.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ResultSetMiscTest.java > ResultSetMetaData.getScale returns inconsistent values for DOUBLE type. > --- > > Key: DERBY-853 > URL: https://issues.apache.org/jira/browse/DERBY-853 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Daniel John Debrunner >Assignee: Danoja Dias >Priority: Trivial > Labels: derby_triage10_5_2 > Attachments: Derby-853.diff, Derby-853_2.diff, Derby-853_3.diff, > Derby853.java > > > If a DOUBLE column is returned in the result set then getScale() returns 0. > If a DOUBLE expression is returned and the expression is the result of a > DOUBLE combined with a DECIMAL then it seems the scale from the decimal > sometimes affects the result set metadata. > E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2. > See the test output for jdbcapi/metadata.java > double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE > double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type > name: DOUBLE > dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type > name: DOUBLE > First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL - > DOUBLE > I assume the scale should always be zero for a DOUBLE, as it holds no > meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial > book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[ https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15402150#comment-15402150 ] Danoja Dias commented on DERBY-853: --- I think this suits for java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ResultSetMiscTest.java I'll add it with a new method. > ResultSetMetaData.getScale returns inconsistent values for DOUBLE type. > --- > > Key: DERBY-853 > URL: https://issues.apache.org/jira/browse/DERBY-853 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Daniel John Debrunner >Assignee: Danoja Dias >Priority: Trivial > Labels: derby_triage10_5_2 > Attachments: Derby-853.diff, Derby-853_2.diff, Derby853.java > > > If a DOUBLE column is returned in the result set then getScale() returns 0. > If a DOUBLE expression is returned and the expression is the result of a > DOUBLE combined with a DECIMAL then it seems the scale from the decimal > sometimes affects the result set metadata. > E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2. > See the test output for jdbcapi/metadata.java > double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE > double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type > name: DOUBLE > dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type > name: DOUBLE > First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL - > DOUBLE > I assume the scale should always be zero for a DOUBLE, as it holds no > meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial > book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6870) Google Summer of Code 2016: Derby bug fixing
[ https://issues.apache.org/jira/browse/DERBY-6870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401589#comment-15401589 ] Danoja Dias commented on DERBY-6870: Linked all bugs that I proposed to fix during this summer. > Google Summer of Code 2016: Derby bug fixing > > > Key: DERBY-6870 > URL: https://issues.apache.org/jira/browse/DERBY-6870 > Project: Derby > Issue Type: Improvement >Reporter: Bryan Pendleton >Assignee: Danoja Dias > Labels: database, gsoc2016, java, jdbc > > For the 2016 Google Summer of Code, I am offering to mentor a > student for general bug fixing of the Derby database. > The Derby JIRA has collected the community's knowledge about > known bugs in Derby, and there are plenty of bugs for us to work on. > If you take on this project, with assistance from me, you'll: > - select Derby issues from the Derby bug tracker to fix > - reproduce those problems by writing and running tests > - develop patches to address the problems > - work with the community to get the patches reviewed > - have your reviewed and accepted contributions committed to the next Derby > release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[ https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401556#comment-15401556 ] Danoja Dias commented on DERBY-853: --- All tests are clean with this patch > ResultSetMetaData.getScale returns inconsistent values for DOUBLE type. > --- > > Key: DERBY-853 > URL: https://issues.apache.org/jira/browse/DERBY-853 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Daniel John Debrunner >Assignee: Danoja Dias >Priority: Trivial > Labels: derby_triage10_5_2 > Attachments: Derby-853.diff, Derby-853_2.diff, Derby853.java > > > If a DOUBLE column is returned in the result set then getScale() returns 0. > If a DOUBLE expression is returned and the expression is the result of a > DOUBLE combined with a DECIMAL then it seems the scale from the decimal > sometimes affects the result set metadata. > E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2. > See the test output for jdbcapi/metadata.java > double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE > double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type > name: DOUBLE > dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type > name: DOUBLE > First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL - > DOUBLE > I assume the scale should always be zero for a DOUBLE, as it holds no > meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial > book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[ https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-853: -- Attachment: Derby-853_2.diff I attached doing changes. This patch also passes the test in Derby853.java > ResultSetMetaData.getScale returns inconsistent values for DOUBLE type. > --- > > Key: DERBY-853 > URL: https://issues.apache.org/jira/browse/DERBY-853 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Daniel John Debrunner >Assignee: Danoja Dias >Priority: Trivial > Labels: derby_triage10_5_2 > Attachments: Derby-853.diff, Derby-853_2.diff, Derby853.java > > > If a DOUBLE column is returned in the result set then getScale() returns 0. > If a DOUBLE expression is returned and the expression is the result of a > DOUBLE combined with a DECIMAL then it seems the scale from the decimal > sometimes affects the result set metadata. > E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2. > See the test output for jdbcapi/metadata.java > double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE > double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type > name: DOUBLE > dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type > name: DOUBLE > First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL - > DOUBLE > I assume the scale should always be zero for a DOUBLE, as it holds no > meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial > book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[
https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danoja Dias updated DERBY-853:
--
Comment: was deleted
(was: {quote}did it fix the Derby853.java test?{quote}
Yes. It fixed Derby853.java test.
{quote}I wonder if there is a way to fix this somewhere near line 258 instead,
because it seems like at line 258 we shouldn't even be calling the
getScale() method if higherType is not a DECIMAL type, so maybe that
call get getScale() should be inside the "if" test at line 260?{quote}
Yes. We shouldn't call getScale() is it is not decimal.
I'll check it and attach a new patch.)
> ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
> ---
>
> Key: DERBY-853
> URL: https://issues.apache.org/jira/browse/DERBY-853
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.2.1.6
>Reporter: Daniel John Debrunner
>Assignee: Danoja Dias
>Priority: Trivial
> Labels: derby_triage10_5_2
> Attachments: Derby-853.diff, Derby853.java
>
>
> If a DOUBLE column is returned in the result set then getScale() returns 0.
> If a DOUBLE expression is returned and the expression is the result of a
> DOUBLE combined with a DECIMAL then it seems the scale from the decimal
> sometimes affects the result set metadata.
> E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2.
> See the test output for jdbcapi/metadata.java
> double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE
> double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type
> name: DOUBLE
> dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type
> name: DOUBLE
> First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL -
> DOUBLE
> I assume the scale should always be zero for a DOUBLE, as it holds no
> meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial
> book.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[
https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danoja Dias updated DERBY-853:
--
Comment: was deleted
(was: {quote}did it fix the Derby853.java test?{quote}
Yes. It fixed Derby853.java test.
{quote}I wonder if there is a way to fix this somewhere near line 258 instead,
because it seems like at line 258 we shouldn't even be calling the
getScale() method if higherType is not a DECIMAL type, so maybe that
call get getScale() should be inside the "if" test at line 260?{quote}
Yes. We shouldn't call getScale() is it is not decimal.
I'll check it and attach a new patch.)
> ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
> ---
>
> Key: DERBY-853
> URL: https://issues.apache.org/jira/browse/DERBY-853
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.2.1.6
>Reporter: Daniel John Debrunner
>Assignee: Danoja Dias
>Priority: Trivial
> Labels: derby_triage10_5_2
> Attachments: Derby-853.diff, Derby853.java
>
>
> If a DOUBLE column is returned in the result set then getScale() returns 0.
> If a DOUBLE expression is returned and the expression is the result of a
> DOUBLE combined with a DECIMAL then it seems the scale from the decimal
> sometimes affects the result set metadata.
> E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2.
> See the test output for jdbcapi/metadata.java
> double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE
> double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type
> name: DOUBLE
> dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type
> name: DOUBLE
> First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL -
> DOUBLE
> I assume the scale should always be zero for a DOUBLE, as it holds no
> meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial
> book.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[
https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401244#comment-15401244
]
Danoja Dias commented on DERBY-853:
---
{quote}did it fix the Derby853.java test?{quote}
Yes. It fixed Derby853.java test.
{quote}I wonder if there is a way to fix this somewhere near line 258 instead,
because it seems like at line 258 we shouldn't even be calling the
getScale() method if higherType is not a DECIMAL type, so maybe that
call get getScale() should be inside the "if" test at line 260?{quote}
Yes. We shouldn't call getScale() is it is not decimal.
I'll check it and attach a new patch.
> ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
> ---
>
> Key: DERBY-853
> URL: https://issues.apache.org/jira/browse/DERBY-853
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.2.1.6
>Reporter: Daniel John Debrunner
>Assignee: Danoja Dias
>Priority: Trivial
> Labels: derby_triage10_5_2
> Attachments: Derby-853.diff, Derby853.java
>
>
> If a DOUBLE column is returned in the result set then getScale() returns 0.
> If a DOUBLE expression is returned and the expression is the result of a
> DOUBLE combined with a DECIMAL then it seems the scale from the decimal
> sometimes affects the result set metadata.
> E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2.
> See the test output for jdbcapi/metadata.java
> double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE
> double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type
> name: DOUBLE
> dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type
> name: DOUBLE
> First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL -
> DOUBLE
> I assume the scale should always be zero for a DOUBLE, as it holds no
> meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial
> book.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[
https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401242#comment-15401242
]
Danoja Dias commented on DERBY-853:
---
{quote}did it fix the Derby853.java test?{quote}
Yes. It fixed Derby853.java test.
{quote}I wonder if there is a way to fix this somewhere near line 258 instead,
because it seems like at line 258 we shouldn't even be calling the
getScale() method if higherType is not a DECIMAL type, so maybe that
call get getScale() should be inside the "if" test at line 260?{quote}
Yes. We shouldn't call getScale() is it is not decimal.
I'll check it and attach a new patch.
> ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
> ---
>
> Key: DERBY-853
> URL: https://issues.apache.org/jira/browse/DERBY-853
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.2.1.6
>Reporter: Daniel John Debrunner
>Assignee: Danoja Dias
>Priority: Trivial
> Labels: derby_triage10_5_2
> Attachments: Derby-853.diff, Derby853.java
>
>
> If a DOUBLE column is returned in the result set then getScale() returns 0.
> If a DOUBLE expression is returned and the expression is the result of a
> DOUBLE combined with a DECIMAL then it seems the scale from the decimal
> sometimes affects the result set metadata.
> E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2.
> See the test output for jdbcapi/metadata.java
> double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE
> double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type
> name: DOUBLE
> dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type
> name: DOUBLE
> First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL -
> DOUBLE
> I assume the scale should always be zero for a DOUBLE, as it holds no
> meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial
> book.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[
https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401243#comment-15401243
]
Danoja Dias commented on DERBY-853:
---
{quote}did it fix the Derby853.java test?{quote}
Yes. It fixed Derby853.java test.
{quote}I wonder if there is a way to fix this somewhere near line 258 instead,
because it seems like at line 258 we shouldn't even be calling the
getScale() method if higherType is not a DECIMAL type, so maybe that
call get getScale() should be inside the "if" test at line 260?{quote}
Yes. We shouldn't call getScale() is it is not decimal.
I'll check it and attach a new patch.
> ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
> ---
>
> Key: DERBY-853
> URL: https://issues.apache.org/jira/browse/DERBY-853
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.2.1.6
>Reporter: Daniel John Debrunner
>Assignee: Danoja Dias
>Priority: Trivial
> Labels: derby_triage10_5_2
> Attachments: Derby-853.diff, Derby853.java
>
>
> If a DOUBLE column is returned in the result set then getScale() returns 0.
> If a DOUBLE expression is returned and the expression is the result of a
> DOUBLE combined with a DECIMAL then it seems the scale from the decimal
> sometimes affects the result set metadata.
> E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2.
> See the test output for jdbcapi/metadata.java
> double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE
> double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type
> name: DOUBLE
> dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type
> name: DOUBLE
> First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL -
> DOUBLE
> I assume the scale should always be zero for a DOUBLE, as it holds no
> meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial
> book.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DERBY-6391) remove unneeded object creation in newException() calls in releases > 10.10
[ https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401231#comment-15401231 ] Danoja Dias commented on DERBY-6391: Yes. Thanks for the detailed explanation. So we can resolve this issue. > remove unneeded object creation in newException() calls in releases > 10.10 > --- > > Key: DERBY-6391 > URL: https://issues.apache.org/jira/browse/DERBY-6391 > Project: Derby > Issue Type: Improvement > Components: SQL, Store >Affects Versions: 10.11.1.1 >Reporter: Mike Matrigali >Assignee: Danoja Dias > Labels: derby_backport_reject_10_10 > Attachments: Derby-6391.diff > > > In releases after 10.10 the code has been converted to use new > java language features. One of the benefits I just noticed is that > arguments to StandardException.newException() no longer have > to be Objects. I believe this is due to reimplementation using varargs. > As an example old code use to have to be written as: > throw StandardException.newException( > SQLState.FILE_BAD_CHECKSUM, > id, > new Long(checksum.getValue()), > new Long(onDiskChecksum), > pagedataToHexDump(pageData)); > The only reason for the new Long() calls was to make them Objects so > that the call would match up to a hard coded N Object arg version of > the newException call. I believe these conversions to Objects are no > longer needed (but formatting of the args might change). > There may be code size savings to be had by doing this code > rototil. > Anyone see a downside to changing the code in this way? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[ https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-853: -- Attachment: Derby-853.diff I attached a patch. Could you please give me any comments about this patch. thanks. > ResultSetMetaData.getScale returns inconsistent values for DOUBLE type. > --- > > Key: DERBY-853 > URL: https://issues.apache.org/jira/browse/DERBY-853 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Daniel John Debrunner >Assignee: Danoja Dias >Priority: Trivial > Labels: derby_triage10_5_2 > Attachments: Derby-853.diff, Derby853.java > > > If a DOUBLE column is returned in the result set then getScale() returns 0. > If a DOUBLE expression is returned and the expression is the result of a > DOUBLE combined with a DECIMAL then it seems the scale from the decimal > sometimes affects the result set metadata. > E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2. > See the test output for jdbcapi/metadata.java > double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE > double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type > name: DOUBLE > dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type > name: DOUBLE > First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL - > DOUBLE > I assume the scale should always be zero for a DOUBLE, as it holds no > meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial > book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6391) remove unneeded object creation in newException() calls in releases > 10.10
[ https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15400921#comment-15400921 ] Danoja Dias commented on DERBY-6391: Yes. But would it arise problems if we commit the attached patch? If not, There will be more new String() object creations in other folders too. Shouldn't we check them? > remove unneeded object creation in newException() calls in releases > 10.10 > --- > > Key: DERBY-6391 > URL: https://issues.apache.org/jira/browse/DERBY-6391 > Project: Derby > Issue Type: Improvement > Components: SQL, Store >Affects Versions: 10.11.1.1 >Reporter: Mike Matrigali >Assignee: Danoja Dias > Labels: derby_backport_reject_10_10 > Attachments: Derby-6391.diff > > > In releases after 10.10 the code has been converted to use new > java language features. One of the benefits I just noticed is that > arguments to StandardException.newException() no longer have > to be Objects. I believe this is due to reimplementation using varargs. > As an example old code use to have to be written as: > throw StandardException.newException( > SQLState.FILE_BAD_CHECKSUM, > id, > new Long(checksum.getValue()), > new Long(onDiskChecksum), > pagedataToHexDump(pageData)); > The only reason for the new Long() calls was to make them Objects so > that the call would match up to a hard coded N Object arg version of > the newException call. I believe these conversions to Objects are no > longer needed (but formatting of the args might change). > There may be code size savings to be had by doing this code > rototil. > Anyone see a downside to changing the code in this way? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6391) remove unneeded object creation in newException() calls in releases > 10.10
[
https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15400895#comment-15400895
]
Danoja Dias commented on DERBY-6391:
Following is quoted from DERBY-6856 comments.
{quote}
There is still a String(char[]) constructor in Java 9
{quote}
Therefore I think there is still object creations of String(char[]) .
I went through all classes in engine folder.
> remove unneeded object creation in newException() calls in releases > 10.10
> ---
>
> Key: DERBY-6391
> URL: https://issues.apache.org/jira/browse/DERBY-6391
> Project: Derby
> Issue Type: Improvement
> Components: SQL, Store
>Affects Versions: 10.11.1.1
>Reporter: Mike Matrigali
>Assignee: Danoja Dias
> Labels: derby_backport_reject_10_10
> Attachments: Derby-6391.diff
>
>
> In releases after 10.10 the code has been converted to use new
> java language features. One of the benefits I just noticed is that
> arguments to StandardException.newException() no longer have
> to be Objects. I believe this is due to reimplementation using varargs.
> As an example old code use to have to be written as:
> throw StandardException.newException(
> SQLState.FILE_BAD_CHECKSUM,
> id,
> new Long(checksum.getValue()),
> new Long(onDiskChecksum),
> pagedataToHexDump(pageData));
> The only reason for the new Long() calls was to make them Objects so
> that the call would match up to a hard coded N Object arg version of
> the newException call. I believe these conversions to Objects are no
> longer needed (but formatting of the args might change).
> There may be code size savings to be had by doing this code
> rototil.
> Anyone see a downside to changing the code in this way?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DERBY-6752) AutoloadedDriver tries to load a non-existent class, AutoloadedDriver40
[ https://issues.apache.org/jira/browse/DERBY-6752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6752: --- Attachment: Derby-6752.diff I attached the patch for this issue. All tests are clean. > AutoloadedDriver tries to load a non-existent class, AutoloadedDriver40 > --- > > Key: DERBY-6752 > URL: https://issues.apache.org/jira/browse/DERBY-6752 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.12.1.1 >Reporter: Rick Hillegas >Assignee: Danoja Dias > Attachments: Derby-6752.diff > > > This happens in a static initialization block at the start of > AutoloadedDriver. Is this dead code? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[ https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15400746#comment-15400746 ] Danoja Dias commented on DERBY-853: --- I think the problem happens in getScale() method in NumericTypeCompiler.java . In this method, getStoredFormatIdFromTypeId() is not equal to Decimal it returns the scale value of leftType. > ResultSetMetaData.getScale returns inconsistent values for DOUBLE type. > --- > > Key: DERBY-853 > URL: https://issues.apache.org/jira/browse/DERBY-853 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Daniel John Debrunner >Assignee: Danoja Dias >Priority: Trivial > Labels: derby_triage10_5_2 > Attachments: Derby853.java > > > If a DOUBLE column is returned in the result set then getScale() returns 0. > If a DOUBLE expression is returned and the expression is the result of a > DOUBLE combined with a DECIMAL then it seems the scale from the decimal > sometimes affects the result set metadata. > E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2. > See the test output for jdbcapi/metadata.java > double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE > double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type > name: DOUBLE > dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type > name: DOUBLE > First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL - > DOUBLE > I assume the scale should always be zero for a DOUBLE, as it holds no > meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial > book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DERBY-853) ResultSetMetaData.getScale returns inconsistent values for DOUBLE type.
[ https://issues.apache.org/jira/browse/DERBY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias reassigned DERBY-853: - Assignee: Danoja Dias > ResultSetMetaData.getScale returns inconsistent values for DOUBLE type. > --- > > Key: DERBY-853 > URL: https://issues.apache.org/jira/browse/DERBY-853 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Daniel John Debrunner >Assignee: Danoja Dias >Priority: Trivial > Labels: derby_triage10_5_2 > Attachments: Derby853.java > > > If a DOUBLE column is returned in the result set then getScale() returns 0. > If a DOUBLE expression is returned and the expression is the result of a > DOUBLE combined with a DECIMAL then it seems the scale from the decimal > sometimes affects the result set metadata. > E.g. DECIMAL(10,2) - DOUBLE returns a DOUBLE with getScale() returning 2. > See the test output for jdbcapi/metadata.java > double -- precision: 15 scale: 0 display size: 22 type name: DOUBLE > double precision - dec(10,2) -- precision: 15 scale: 0 display size: 22 type > name: DOUBLE > dec(10,2) - double precision -- precision: 15 scale: 2 display size: 22 type > name: DOUBLE > First line is a DOUBLE column, second is DOUBLE - DECIMAL, third is DECIMAL - > DOUBLE > I assume the scale should always be zero for a DOUBLE, as it holds no > meaning, but I can't see any proof of that in JDBC spec, javadoc or tutorial > book. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DERBY-6752) AutoloadedDriver tries to load a non-existent class, AutoloadedDriver40
[ https://issues.apache.org/jira/browse/DERBY-6752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias reassigned DERBY-6752: -- Assignee: Danoja Dias > AutoloadedDriver tries to load a non-existent class, AutoloadedDriver40 > --- > > Key: DERBY-6752 > URL: https://issues.apache.org/jira/browse/DERBY-6752 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.12.1.1 >Reporter: Rick Hillegas >Assignee: Danoja Dias > > This happens in a static initialization block at the start of > AutoloadedDriver. Is this dead code? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6391) remove unneeded object creation in newException() calls in releases > 10.10
[ https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15400601#comment-15400601 ] Danoja Dias commented on DERBY-6391: I went through DERBY-6856 Comments. All unneeded object creations are removed. So we can close this issue. > remove unneeded object creation in newException() calls in releases > 10.10 > --- > > Key: DERBY-6391 > URL: https://issues.apache.org/jira/browse/DERBY-6391 > Project: Derby > Issue Type: Improvement > Components: SQL, Store >Affects Versions: 10.11.1.1 >Reporter: Mike Matrigali >Assignee: Danoja Dias > Labels: derby_backport_reject_10_10 > Attachments: Derby-6391.diff > > > In releases after 10.10 the code has been converted to use new > java language features. One of the benefits I just noticed is that > arguments to StandardException.newException() no longer have > to be Objects. I believe this is due to reimplementation using varargs. > As an example old code use to have to be written as: > throw StandardException.newException( > SQLState.FILE_BAD_CHECKSUM, > id, > new Long(checksum.getValue()), > new Long(onDiskChecksum), > pagedataToHexDump(pageData)); > The only reason for the new Long() calls was to make them Objects so > that the call would match up to a hard coded N Object arg version of > the newException call. I believe these conversions to Objects are no > longer needed (but formatting of the args might change). > There may be code size savings to be had by doing this code > rototil. > Anyone see a downside to changing the code in this way? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6391) remove unneeded object creation in newException() calls in releases > 10.10
[ https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15400432#comment-15400432 ] Danoja Dias commented on DERBY-6391: Thanks for the suggestion to find exception calls in an easy way. > remove unneeded object creation in newException() calls in releases > 10.10 > --- > > Key: DERBY-6391 > URL: https://issues.apache.org/jira/browse/DERBY-6391 > Project: Derby > Issue Type: Improvement > Components: SQL, Store >Affects Versions: 10.11.1.1 >Reporter: Mike Matrigali >Assignee: Danoja Dias > Labels: derby_backport_reject_10_10 > Attachments: Derby-6391.diff > > > In releases after 10.10 the code has been converted to use new > java language features. One of the benefits I just noticed is that > arguments to StandardException.newException() no longer have > to be Objects. I believe this is due to reimplementation using varargs. > As an example old code use to have to be written as: > throw StandardException.newException( > SQLState.FILE_BAD_CHECKSUM, > id, > new Long(checksum.getValue()), > new Long(onDiskChecksum), > pagedataToHexDump(pageData)); > The only reason for the new Long() calls was to make them Objects so > that the call would match up to a hard coded N Object arg version of > the newException call. I believe these conversions to Objects are no > longer needed (but formatting of the args might change). > There may be code size savings to be had by doing this code > rototil. > Anyone see a downside to changing the code in this way? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DERBY-6391) remove unneeded object creation in newException() calls in releases > 10.10
[ https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias reassigned DERBY-6391: -- Assignee: Danoja Dias > remove unneeded object creation in newException() calls in releases > 10.10 > --- > > Key: DERBY-6391 > URL: https://issues.apache.org/jira/browse/DERBY-6391 > Project: Derby > Issue Type: Improvement > Components: SQL, Store >Affects Versions: 10.11.1.1 >Reporter: Mike Matrigali >Assignee: Danoja Dias > Labels: derby_backport_reject_10_10 > Attachments: Derby-6391.diff > > > In releases after 10.10 the code has been converted to use new > java language features. One of the benefits I just noticed is that > arguments to StandardException.newException() no longer have > to be Objects. I believe this is due to reimplementation using varargs. > As an example old code use to have to be written as: > throw StandardException.newException( > SQLState.FILE_BAD_CHECKSUM, > id, > new Long(checksum.getValue()), > new Long(onDiskChecksum), > pagedataToHexDump(pageData)); > The only reason for the new Long() calls was to make them Objects so > that the call would match up to a hard coded N Object arg version of > the newException call. I believe these conversions to Objects are no > longer needed (but formatting of the args might change). > There may be code size savings to be had by doing this code > rototil. > Anyone see a downside to changing the code in this way? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6391) remove unneeded object creation in newException() calls in releases > 10.10
[ https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6391: --- Attachment: Derby-6391.diff > remove unneeded object creation in newException() calls in releases > 10.10 > --- > > Key: DERBY-6391 > URL: https://issues.apache.org/jira/browse/DERBY-6391 > Project: Derby > Issue Type: Improvement > Components: SQL, Store >Affects Versions: 10.11.1.1 >Reporter: Mike Matrigali > Labels: derby_backport_reject_10_10 > Attachments: Derby-6391.diff > > > In releases after 10.10 the code has been converted to use new > java language features. One of the benefits I just noticed is that > arguments to StandardException.newException() no longer have > to be Objects. I believe this is due to reimplementation using varargs. > As an example old code use to have to be written as: > throw StandardException.newException( > SQLState.FILE_BAD_CHECKSUM, > id, > new Long(checksum.getValue()), > new Long(onDiskChecksum), > pagedataToHexDump(pageData)); > The only reason for the new Long() calls was to make them Objects so > that the call would match up to a hard coded N Object arg version of > the newException call. I believe these conversions to Objects are no > longer needed (but formatting of the args might change). > There may be code size savings to be had by doing this code > rototil. > Anyone see a downside to changing the code in this way? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6391) remove unneeded object creation in newException() calls in releases > 10.10
[ https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15400430#comment-15400430 ] Danoja Dias commented on DERBY-6391: I should have commented this before as I spent a considerable time on this without knowing this has been already done. :) I went through many classes and didn't find many such object creations. I found one so far and I'll attach it. I looked at diffs. But can we be sure that all such unneeded object creations are removed? > remove unneeded object creation in newException() calls in releases > 10.10 > --- > > Key: DERBY-6391 > URL: https://issues.apache.org/jira/browse/DERBY-6391 > Project: Derby > Issue Type: Improvement > Components: SQL, Store >Affects Versions: 10.11.1.1 >Reporter: Mike Matrigali > Labels: derby_backport_reject_10_10 > > In releases after 10.10 the code has been converted to use new > java language features. One of the benefits I just noticed is that > arguments to StandardException.newException() no longer have > to be Objects. I believe this is due to reimplementation using varargs. > As an example old code use to have to be written as: > throw StandardException.newException( > SQLState.FILE_BAD_CHECKSUM, > id, > new Long(checksum.getValue()), > new Long(onDiskChecksum), > pagedataToHexDump(pageData)); > The only reason for the new Long() calls was to make them Objects so > that the call would match up to a hard coded N Object arg version of > the newException call. I believe these conversions to Objects are no > longer needed (but formatting of the args might change). > There may be code size savings to be had by doing this code > rototil. > Anyone see a downside to changing the code in this way? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6391) remove unneeded object creation in newException() calls in releases > 10.10
[ https://issues.apache.org/jira/browse/DERBY-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15399511#comment-15399511 ] Danoja Dias commented on DERBY-6391: In DERBY-5873 this is already done for client and server. So I started doing this for the classes in engine folder. Now what I do is, finding the Exception keyword and check whether there is a object creation. Most times, There is no creation of objects. I find it bit hard to find where these object creations happens. Is there a simple and easy way to find out where these object creation happens. > remove unneeded object creation in newException() calls in releases > 10.10 > --- > > Key: DERBY-6391 > URL: https://issues.apache.org/jira/browse/DERBY-6391 > Project: Derby > Issue Type: Improvement > Components: SQL, Store >Affects Versions: 10.11.1.1 >Reporter: Mike Matrigali > Labels: derby_backport_reject_10_10 > > In releases after 10.10 the code has been converted to use new > java language features. One of the benefits I just noticed is that > arguments to StandardException.newException() no longer have > to be Objects. I believe this is due to reimplementation using varargs. > As an example old code use to have to be written as: > throw StandardException.newException( > SQLState.FILE_BAD_CHECKSUM, > id, > new Long(checksum.getValue()), > new Long(onDiskChecksum), > pagedataToHexDump(pageData)); > The only reason for the new Long() calls was to make them Objects so > that the call would match up to a hard coded N Object arg version of > the newException call. I believe these conversions to Objects are no > longer needed (but formatting of the args might change). > There may be code size savings to be had by doing this code > rototil. > Anyone see a downside to changing the code in this way? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-5585) Improve error messages used when Derby can't find the class or method backing up a SQL routine or type
[ https://issues.apache.org/jira/browse/DERBY-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-5585: --- Attachment: Derby5585_3.diff With Derby5585_3.diff patch tests were fine. > Improve error messages used when Derby can't find the class or method backing > up a SQL routine or type > -- > > Key: DERBY-5585 > URL: https://issues.apache.org/jira/browse/DERBY-5585 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.9.1.0 >Reporter: Rick Hillegas >Assignee: Danoja Dias >Priority: Minor > Labels: derby_triage10_10 > Fix For: 10.13.0.0 > > Attachments: Derby-5585.diff, Derby-5585_2.diff, Derby5585_3.diff, > errors.zip > > > When the code supporting user-written routines and types is put into jar > files in the database, the user also needs to wire the jar files together by > setting the derby.database.classpath property. People often neglect to do > this and Derby documentation in this area could be improved. It would be good > to at least improve the error messages which Derby raises in this situation: > 42X50 and 42X51. Those messages should tell the user that one of the reasons > for the failure might be an un/misconfigured derby.database.classpath > property. The following script shows the error messages: > connect > 'jdbc:derby:memory:db;create=true;user=test_dbo;password=test_dbopassword'; > create function foo( a int ) returns int > language java parameter style java no sql > external name 'Bop.doowop'; > create function bar( a int ) returns int > language java parameter style java no sql > external name 'java.lang.Integer.doowop'; > values ( foo( 1 ) ); > values ( bar( 1 ) ); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-5585) Improve error messages used when Derby can't find the class or method backing up a SQL routine or type
[ https://issues.apache.org/jira/browse/DERBY-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15398726#comment-15398726 ] Danoja Dias commented on DERBY-5585: Oh, I'll look at it. > Improve error messages used when Derby can't find the class or method backing > up a SQL routine or type > -- > > Key: DERBY-5585 > URL: https://issues.apache.org/jira/browse/DERBY-5585 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.9.1.0 >Reporter: Rick Hillegas >Assignee: Danoja Dias >Priority: Minor > Labels: derby_triage10_10 > Fix For: 10.13.0.0 > > Attachments: Derby-5585.diff, Derby-5585_2.diff, errors.zip > > > When the code supporting user-written routines and types is put into jar > files in the database, the user also needs to wire the jar files together by > setting the derby.database.classpath property. People often neglect to do > this and Derby documentation in this area could be improved. It would be good > to at least improve the error messages which Derby raises in this situation: > 42X50 and 42X51. Those messages should tell the user that one of the reasons > for the failure might be an un/misconfigured derby.database.classpath > property. The following script shows the error messages: > connect > 'jdbc:derby:memory:db;create=true;user=test_dbo;password=test_dbopassword'; > create function foo( a int ) returns int > language java parameter style java no sql > external name 'Bop.doowop'; > create function bar( a int ) returns int > language java parameter style java no sql > external name 'java.lang.Integer.doowop'; > values ( foo( 1 ) ); > values ( bar( 1 ) ); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-5585) Improve error messages used when Derby can't find the class or method backing up a SQL routine or type
[ https://issues.apache.org/jira/browse/DERBY-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-5585: --- Attachment: Derby-5585_2.diff I attached new patch with tests and changed error messages. > Improve error messages used when Derby can't find the class or method backing > up a SQL routine or type > -- > > Key: DERBY-5585 > URL: https://issues.apache.org/jira/browse/DERBY-5585 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.9.1.0 >Reporter: Rick Hillegas >Assignee: Danoja Dias >Priority: Minor > Labels: derby_triage10_10 > Attachments: Derby-5585.diff, Derby-5585_2.diff > > > When the code supporting user-written routines and types is put into jar > files in the database, the user also needs to wire the jar files together by > setting the derby.database.classpath property. People often neglect to do > this and Derby documentation in this area could be improved. It would be good > to at least improve the error messages which Derby raises in this situation: > 42X50 and 42X51. Those messages should tell the user that one of the reasons > for the failure might be an un/misconfigured derby.database.classpath > property. The following script shows the error messages: > connect > 'jdbc:derby:memory:db;create=true;user=test_dbo;password=test_dbopassword'; > create function foo( a int ) returns int > language java parameter style java no sql > external name 'Bop.doowop'; > create function bar( a int ) returns int > language java parameter style java no sql > external name 'java.lang.Integer.doowop'; > values ( foo( 1 ) ); > values ( bar( 1 ) ); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-5585) Improve error messages used when Derby can't find the class or method backing up a SQL routine or type
[ https://issues.apache.org/jira/browse/DERBY-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-5585: --- Attachment: Derby-5585.diff I added the patch that improves the error message. Is there an more to do with this? > Improve error messages used when Derby can't find the class or method backing > up a SQL routine or type > -- > > Key: DERBY-5585 > URL: https://issues.apache.org/jira/browse/DERBY-5585 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.9.1.0 >Reporter: Rick Hillegas >Priority: Minor > Labels: derby_triage10_10 > Attachments: Derby-5585.diff > > > When the code supporting user-written routines and types is put into jar > files in the database, the user also needs to wire the jar files together by > setting the derby.database.classpath property. People often neglect to do > this and Derby documentation in this area could be improved. It would be good > to at least improve the error messages which Derby raises in this situation: > 42X50 and 42X51. Those messages should tell the user that one of the reasons > for the failure might be an un/misconfigured derby.database.classpath > property. The following script shows the error messages: > connect > 'jdbc:derby:memory:db;create=true;user=test_dbo;password=test_dbopassword'; > create function foo( a int ) returns int > language java parameter style java no sql > external name 'Bop.doowop'; > create function bar( a int ) returns int > language java parameter style java no sql > external name 'java.lang.Integer.doowop'; > values ( foo( 1 ) ); > values ( bar( 1 ) ); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DERBY-5585) Improve error messages used when Derby can't find the class or method backing up a SQL routine or type
[ https://issues.apache.org/jira/browse/DERBY-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias reassigned DERBY-5585: -- Assignee: Danoja Dias > Improve error messages used when Derby can't find the class or method backing > up a SQL routine or type > -- > > Key: DERBY-5585 > URL: https://issues.apache.org/jira/browse/DERBY-5585 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.9.1.0 >Reporter: Rick Hillegas >Assignee: Danoja Dias >Priority: Minor > Labels: derby_triage10_10 > Attachments: Derby-5585.diff > > > When the code supporting user-written routines and types is put into jar > files in the database, the user also needs to wire the jar files together by > setting the derby.database.classpath property. People often neglect to do > this and Derby documentation in this area could be improved. It would be good > to at least improve the error messages which Derby raises in this situation: > 42X50 and 42X51. Those messages should tell the user that one of the reasons > for the failure might be an un/misconfigured derby.database.classpath > property. The following script shows the error messages: > connect > 'jdbc:derby:memory:db;create=true;user=test_dbo;password=test_dbopassword'; > create function foo( a int ) returns int > language java parameter style java no sql > external name 'Bop.doowop'; > create function bar( a int ) returns int > language java parameter style java no sql > external name 'java.lang.Integer.doowop'; > values ( foo( 1 ) ); > values ( bar( 1 ) ); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-3600) Change replication methods in org.apache.derby.iapi.db.Database to throw StandardException instead of SQLException
[ https://issues.apache.org/jira/browse/DERBY-3600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15394098#comment-15394098 ] Danoja Dias commented on DERBY-3600: Then it will be a risk of doing this. We can close this issue. > Change replication methods in org.apache.derby.iapi.db.Database to throw > StandardException instead of SQLException > -- > > Key: DERBY-3600 > URL: https://issues.apache.org/jira/browse/DERBY-3600 > Project: Derby > Issue Type: Improvement > Components: Replication >Affects Versions: 10.6.1.0 >Reporter: V.Narayanan >Assignee: Danoja Dias >Priority: Minor > Attachments: derby-3600.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6901) SYSCS_IMPORT_TABLE_BULK , SYSCS_IMPORT_DATA_BULK gives two different line numbers in the same error message.
[ https://issues.apache.org/jira/browse/DERBY-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6901: --- Attachment: repro.java petlist.csv > SYSCS_IMPORT_TABLE_BULK , SYSCS_IMPORT_DATA_BULK gives two different line > numbers in the same error message. > > > Key: DERBY-6901 > URL: https://issues.apache.org/jira/browse/DERBY-6901 > Project: Derby > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 10.13.0.0 >Reporter: Danoja Dias >Priority: Minor > Attachments: petlist.csv, repro.java > > > SYSCS_IMPORT_TABLE_BULK and SYSCS_IMPORT_DATA_BULK procedures gives two > different line numbers in same error message. > For a test like following > cSt = prepareCall( > " call SYSCS_UTIL.SYSCS_IMPORT_DATA_BULK(null, " > + "'PET' , null , '1,2,3' , 'extinout/pet.dat' " > + " , null , null , null, 0, 7) "); > it gives the error message > [junit] Import error on line 1 of file extinout/pet.dat: Read end of file at > unexpected place on line 7. > Note : pet.dat file has only 6 lines to be imported. > There are multiple objects of importReadData. One is used by readHeaders() > method in Import.java which is maintaining its own lineNumber. > The problem involves the fact that the Import object and the ImportReadData > object are two separate objects, and the Import object has a "lineNumber" > (which is actually in the ImportAbstract superclass), and the ImportReadData > object has a separate "lineNumber". > It's possible that if ImportAbstract.getCurrentLineNumber() > were changed so that it checked to see if its importReadData > member was non-NULL, and then returned > importReadData.getCurrentRowNumber() rather than simply always > returning its own lineNumber, then these error messages would > report the lineNumber better in more cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6901) SYSCS_IMPORT_TABLE_BULK , SYSCS_IMPORT_DATA_BULK gives two different line numbers in the same error message.
[ https://issues.apache.org/jira/browse/DERBY-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6901: --- External issue URL: (was: https://issues.apache.org/jira/browse/DERBY-4555#) > SYSCS_IMPORT_TABLE_BULK , SYSCS_IMPORT_DATA_BULK gives two different line > numbers in the same error message. > > > Key: DERBY-6901 > URL: https://issues.apache.org/jira/browse/DERBY-6901 > Project: Derby > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 10.13.0.0 >Reporter: Danoja Dias >Priority: Minor > > SYSCS_IMPORT_TABLE_BULK and SYSCS_IMPORT_DATA_BULK procedures gives two > different line numbers in same error message. > For a test like following > cSt = prepareCall( > " call SYSCS_UTIL.SYSCS_IMPORT_DATA_BULK(null, " > + "'PET' , null , '1,2,3' , 'extinout/pet.dat' " > + " , null , null , null, 0, 7) "); > it gives the error message > [junit] Import error on line 1 of file extinout/pet.dat: Read end of file at > unexpected place on line 7. > Note : pet.dat file has only 6 lines to be imported. > There are multiple objects of importReadData. One is used by readHeaders() > method in Import.java which is maintaining its own lineNumber. > The problem involves the fact that the Import object and the ImportReadData > object are two separate objects, and the Import object has a "lineNumber" > (which is actually in the ImportAbstract superclass), and the ImportReadData > object has a separate "lineNumber". > It's possible that if ImportAbstract.getCurrentLineNumber() > were changed so that it checked to see if its importReadData > member was non-NULL, and then returned > importReadData.getCurrentRowNumber() rather than simply always > returning its own lineNumber, then these error messages would > report the lineNumber better in more cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DERBY-6901) SYSCS_IMPORT_TABLE_BULK , SYSCS_IMPORT_DATA_BULK gives two different line numbers in the same error message.
Danoja Dias created DERBY-6901: -- Summary: SYSCS_IMPORT_TABLE_BULK , SYSCS_IMPORT_DATA_BULK gives two different line numbers in the same error message. Key: DERBY-6901 URL: https://issues.apache.org/jira/browse/DERBY-6901 Project: Derby Issue Type: Bug Components: Miscellaneous Affects Versions: 10.13.0.0 Reporter: Danoja Dias Priority: Minor SYSCS_IMPORT_TABLE_BULK and SYSCS_IMPORT_DATA_BULK procedures gives two different line numbers in same error message. For a test like following cSt = prepareCall( " call SYSCS_UTIL.SYSCS_IMPORT_DATA_BULK(null, " + "'PET' , null , '1,2,3' , 'extinout/pet.dat' " + " , null , null , null, 0, 7) "); it gives the error message [junit] Import error on line 1 of file extinout/pet.dat: Read end of file at unexpected place on line 7. Note : pet.dat file has only 6 lines to be imported. There are multiple objects of importReadData. One is used by readHeaders() method in Import.java which is maintaining its own lineNumber. The problem involves the fact that the Import object and the ImportReadData object are two separate objects, and the Import object has a "lineNumber" (which is actually in the ImportAbstract superclass), and the ImportReadData object has a separate "lineNumber". It's possible that if ImportAbstract.getCurrentLineNumber() were changed so that it checked to see if its importReadData member was non-NULL, and then returned importReadData.getCurrentRowNumber() rather than simply always returning its own lineNumber, then these error messages would report the lineNumber better in more cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-4555) Expand SYSCS_IMPORT_TABLE to accept CSV file with header lines
[ https://issues.apache.org/jira/browse/DERBY-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392046#comment-15392046 ] Danoja Dias commented on DERBY-4555: I tried the suggested method. They do not resolve the test cases that are mentioned here. But It will give better line numbers in error messages in some cases. What would be the next step? Since this is over-and-above the scope, Should we create a new issue or resolve this issue. > Expand SYSCS_IMPORT_TABLE to accept CSV file with header lines > -- > > Key: DERBY-4555 > URL: https://issues.apache.org/jira/browse/DERBY-4555 > Project: Derby > Issue Type: Improvement > Components: Miscellaneous >Reporter: Yair Lenga >Assignee: Danoja Dias > Attachments: LineNumberIssue.diff, NoVarargs.diff, Varargs.diff, > addNewSystemProcedureWithTest.diff, addNewSystemProcedureWithTest_1.diff, > addNewSystemProcedure_1.diff, gotException.diff, hardCoded.diff, latest.diff, > noHeaderLines.csv, petlist.csv, petlist.csv, petlist.csv, repro.java, > repro.java, repro.java, skipHeaders.diff > > > The SYSCS_IMPORT_TABLE (and SYSCS_IMPORT_DATA) function allow import of data > from external resources. In general, they can process CSV files that created > with various tools - with one exception: the header line. > While there is no accepted standard, most tools will include a header line in > the CSV file with column names. This convention is supported in Excel and > many other tools. > My Request: extend the SYSCS_IMPORT_TABLe and SYSCS_IMPORT_DATA (and other > related procedures) to include an extra indicator for the number of header > lines to be ignored. > As an extra bonus it will be help is the SYSCS_IMPORT_DATA will accept column > names (instead of column indexes) in the 'COLUMNINDEXES' arguments. E.g., it > should be possible to indicate COLUMNINDEXES of '1,3,sales,5,'. This feature > will make it significantly easier to handle cases where the external input > files is extended to include additional columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-3600) Change replication methods in org.apache.derby.iapi.db.Database to throw StandardException instead of SQLException
[ https://issues.apache.org/jira/browse/DERBY-3600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391565#comment-15391565 ] Danoja Dias commented on DERBY-3600: I checked mail archives and found that this is a part of DERBY-3455 > Change replication methods in org.apache.derby.iapi.db.Database to throw > StandardException instead of SQLException > -- > > Key: DERBY-3600 > URL: https://issues.apache.org/jira/browse/DERBY-3600 > Project: Derby > Issue Type: Improvement > Components: Replication >Affects Versions: 10.6.1.0 >Reporter: V.Narayanan >Assignee: Danoja Dias >Priority: Minor > Attachments: derby-3600.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-3600) Change replication methods in org.apache.derby.iapi.db.Database to throw StandardException instead of SQLException
[ https://issues.apache.org/jira/browse/DERBY-3600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391486#comment-15391486 ] Danoja Dias commented on DERBY-3600: This is a part of DERBY-3455. Linking DERBY-3455 to this issue. > Change replication methods in org.apache.derby.iapi.db.Database to throw > StandardException instead of SQLException > -- > > Key: DERBY-3600 > URL: https://issues.apache.org/jira/browse/DERBY-3600 > Project: Derby > Issue Type: Improvement > Components: Replication >Affects Versions: 10.6.1.0 >Reporter: V.Narayanan >Assignee: Danoja Dias >Priority: Minor > Attachments: derby-3600.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-3600) Change replication methods in org.apache.derby.iapi.db.Database to throw StandardException instead of SQLException
[
https://issues.apache.org/jira/browse/DERBY-3600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391095#comment-15391095
]
Danoja Dias commented on DERBY-3600:
{quote}
What sort of testing have you done? Have you been able to detect
any changes in behavior due to this change?
{quote}
I ran all tests and they were clean. I didn't find any changes due to this.
I also had the problem that why we should do this.
> Change replication methods in org.apache.derby.iapi.db.Database to throw
> StandardException instead of SQLException
> --
>
> Key: DERBY-3600
> URL: https://issues.apache.org/jira/browse/DERBY-3600
> Project: Derby
> Issue Type: Improvement
> Components: Replication
>Affects Versions: 10.6.1.0
>Reporter: V.Narayanan
>Assignee: Danoja Dias
>Priority: Minor
> Attachments: derby-3600.diff
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DERBY-3600) Change replication methods in org.apache.derby.iapi.db.Database to throw StandardException instead of SQLException
[ https://issues.apache.org/jira/browse/DERBY-3600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-3600: --- Attachment: derby-3600.diff I added the patch to throw StandardException instead of SQLException. > Change replication methods in org.apache.derby.iapi.db.Database to throw > StandardException instead of SQLException > -- > > Key: DERBY-3600 > URL: https://issues.apache.org/jira/browse/DERBY-3600 > Project: Derby > Issue Type: Improvement > Components: Replication >Affects Versions: 10.6.1.0 >Reporter: V.Narayanan >Assignee: Danoja Dias >Priority: Minor > Attachments: derby-3600.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DERBY-3600) Change replication methods in org.apache.derby.iapi.db.Database to throw StandardException instead of SQLException
[ https://issues.apache.org/jira/browse/DERBY-3600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias reassigned DERBY-3600: -- Assignee: Danoja Dias > Change replication methods in org.apache.derby.iapi.db.Database to throw > StandardException instead of SQLException > -- > > Key: DERBY-3600 > URL: https://issues.apache.org/jira/browse/DERBY-3600 > Project: Derby > Issue Type: Improvement > Components: Replication >Affects Versions: 10.6.1.0 >Reporter: V.Narayanan >Assignee: Danoja Dias >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-4555) Expand SYSCS_IMPORT_TABLE to accept CSV file with header lines
[
https://issues.apache.org/jira/browse/DERBY-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15389498#comment-15389498
]
Danoja Dias commented on DERBY-4555:
I found this, when I run test case skip==7 test using repro.java
It shows me line number = 1.
I think this issue doesn't seem like a terribly likely case. Anyway user can
guess where the error happens with the current error message too.
Is there a way to test the arguments that passes to Error messsage?
In message.xml
{code}
XIE0E.S
Read end of file at unexpected place on line {0}.
lineNumber
{code}
Can we test argument here?
> Expand SYSCS_IMPORT_TABLE to accept CSV file with header lines
> --
>
> Key: DERBY-4555
> URL: https://issues.apache.org/jira/browse/DERBY-4555
> Project: Derby
> Issue Type: Improvement
> Components: Miscellaneous
>Reporter: Yair Lenga
>Assignee: Danoja Dias
> Attachments: LineNumberIssue.diff, NoVarargs.diff, Varargs.diff,
> addNewSystemProcedureWithTest.diff, addNewSystemProcedureWithTest_1.diff,
> addNewSystemProcedure_1.diff, gotException.diff, hardCoded.diff, latest.diff,
> noHeaderLines.csv, petlist.csv, petlist.csv, petlist.csv, repro.java,
> repro.java, repro.java, skipHeaders.diff
>
>
> The SYSCS_IMPORT_TABLE (and SYSCS_IMPORT_DATA) function allow import of data
> from external resources. In general, they can process CSV files that created
> with various tools - with one exception: the header line.
> While there is no accepted standard, most tools will include a header line in
> the CSV file with column names. This convention is supported in Excel and
> many other tools.
> My Request: extend the SYSCS_IMPORT_TABLe and SYSCS_IMPORT_DATA (and other
> related procedures) to include an extra indicator for the number of header
> lines to be ignored.
> As an extra bonus it will be help is the SYSCS_IMPORT_DATA will accept column
> names (instead of column indexes) in the 'COLUMNINDEXES' arguments. E.g., it
> should be possible to indicate COLUMNINDEXES of '1,3,sales,5,'. This feature
> will make it significantly easier to handle cases where the external input
> files is extended to include additional columns.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[ https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15388766#comment-15388766 ] Danoja Dias commented on DERBY-6852: No it will also gives me error 42X01. I tried several ways but didn't succeed. > Allow identity columns to cycle (as defined in SQL:2003) > > > Key: DERBY-6852 > URL: https://issues.apache.org/jira/browse/DERBY-6852 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Peter Hansson >Assignee: Danoja Dias > Attachments: derby-6852_1.diff, derby_6852_2.diff, script.sql > > > Currently when an IDENTITY column reaches its maximum value it will produce > an error. > For tables that are used as 'transaction logs' or 'event logs' it often makes > sense to let the table automatically start over with the first identity value > again when the max is reached. This would be similar to the CYCLE option on > Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used > quite often for this purpose, I guess, perhaps even more than other RDBMSs. > At the moment every developer have to program their own logic for this. > I propose to introduce the CYCLE option. > The idea of CYCLE is based on the assumption that there's been a prior > cleanup in the table rows so that it will be possible to re-use ids that have > been used previously. If that is not the case - and a rollover happens - then > a duplicate value error will occur. In this sense it can be argued that the > CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby > users would possibly gladly accept such a bargain. In other words: This > option will greatly enhance the usability of IDENTITY columns. > The current implementation of IDENTITY columns SQL grammar in Derby is a > subset of the SQL:2003 standard which is the first of the SQL standards to > define IDENTITY columns. Interestingly the standard also defines the CYCLE > option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003 > features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures] > (scroll to T174). > In other words: The proposal is simply to implement CYCLE as defined in > SQL:2003. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-4555) Expand SYSCS_IMPORT_TABLE to accept CSV file with header lines
[ https://issues.apache.org/jira/browse/DERBY-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15388755#comment-15388755 ] Danoja Dias commented on DERBY-4555: I attached LineNumberIssue.diff that resolves it. > Expand SYSCS_IMPORT_TABLE to accept CSV file with header lines > -- > > Key: DERBY-4555 > URL: https://issues.apache.org/jira/browse/DERBY-4555 > Project: Derby > Issue Type: Improvement > Components: Miscellaneous >Reporter: Yair Lenga >Assignee: Danoja Dias > Attachments: LineNumberIssue.diff, NoVarargs.diff, Varargs.diff, > addNewSystemProcedureWithTest.diff, addNewSystemProcedureWithTest_1.diff, > addNewSystemProcedure_1.diff, gotException.diff, hardCoded.diff, latest.diff, > noHeaderLines.csv, petlist.csv, petlist.csv, petlist.csv, repro.java, > repro.java, repro.java, skipHeaders.diff > > > The SYSCS_IMPORT_TABLE (and SYSCS_IMPORT_DATA) function allow import of data > from external resources. In general, they can process CSV files that created > with various tools - with one exception: the header line. > While there is no accepted standard, most tools will include a header line in > the CSV file with column names. This convention is supported in Excel and > many other tools. > My Request: extend the SYSCS_IMPORT_TABLe and SYSCS_IMPORT_DATA (and other > related procedures) to include an extra indicator for the number of header > lines to be ignored. > As an extra bonus it will be help is the SYSCS_IMPORT_DATA will accept column > names (instead of column indexes) in the 'COLUMNINDEXES' arguments. E.g., it > should be possible to indicate COLUMNINDEXES of '1,3,sales,5,'. This feature > will make it significantly easier to handle cases where the external input > files is extended to include additional columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-4555) Expand SYSCS_IMPORT_TABLE to accept CSV file with header lines
[ https://issues.apache.org/jira/browse/DERBY-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-4555: --- Attachment: LineNumberIssue.diff > Expand SYSCS_IMPORT_TABLE to accept CSV file with header lines > -- > > Key: DERBY-4555 > URL: https://issues.apache.org/jira/browse/DERBY-4555 > Project: Derby > Issue Type: Improvement > Components: Miscellaneous >Reporter: Yair Lenga >Assignee: Danoja Dias > Attachments: LineNumberIssue.diff, NoVarargs.diff, Varargs.diff, > addNewSystemProcedureWithTest.diff, addNewSystemProcedureWithTest_1.diff, > addNewSystemProcedure_1.diff, gotException.diff, hardCoded.diff, latest.diff, > noHeaderLines.csv, petlist.csv, petlist.csv, petlist.csv, repro.java, > repro.java, repro.java, skipHeaders.diff > > > The SYSCS_IMPORT_TABLE (and SYSCS_IMPORT_DATA) function allow import of data > from external resources. In general, they can process CSV files that created > with various tools - with one exception: the header line. > While there is no accepted standard, most tools will include a header line in > the CSV file with column names. This convention is supported in Excel and > many other tools. > My Request: extend the SYSCS_IMPORT_TABLe and SYSCS_IMPORT_DATA (and other > related procedures) to include an extra indicator for the number of header > lines to be ignored. > As an extra bonus it will be help is the SYSCS_IMPORT_DATA will accept column > names (instead of column indexes) in the 'COLUMNINDEXES' arguments. E.g., it > should be possible to indicate COLUMNINDEXES of '1,3,sales,5,'. This feature > will make it significantly easier to handle cases where the external input > files is extended to include additional columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-4555) Expand SYSCS_IMPORT_TABLE to accept CSV file with header lines
[ https://issues.apache.org/jira/browse/DERBY-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15388754#comment-15388754 ] Danoja Dias commented on DERBY-4555: When we skip the header lines, in ignoreHeaderLines() method in ImportReadData.java it does not update the value of lineNumber. When an error occurs it shows a wrong line number. I think we should add it. If not the line number of the input data file is wrong. I didn't notice this problem before. sorry about that. > Expand SYSCS_IMPORT_TABLE to accept CSV file with header lines > -- > > Key: DERBY-4555 > URL: https://issues.apache.org/jira/browse/DERBY-4555 > Project: Derby > Issue Type: Improvement > Components: Miscellaneous >Reporter: Yair Lenga >Assignee: Danoja Dias > Attachments: NoVarargs.diff, Varargs.diff, > addNewSystemProcedureWithTest.diff, addNewSystemProcedureWithTest_1.diff, > addNewSystemProcedure_1.diff, gotException.diff, hardCoded.diff, latest.diff, > noHeaderLines.csv, petlist.csv, petlist.csv, petlist.csv, repro.java, > repro.java, repro.java, skipHeaders.diff > > > The SYSCS_IMPORT_TABLE (and SYSCS_IMPORT_DATA) function allow import of data > from external resources. In general, they can process CSV files that created > with various tools - with one exception: the header line. > While there is no accepted standard, most tools will include a header line in > the CSV file with column names. This convention is supported in Excel and > many other tools. > My Request: extend the SYSCS_IMPORT_TABLe and SYSCS_IMPORT_DATA (and other > related procedures) to include an extra indicator for the number of header > lines to be ignored. > As an extra bonus it will be help is the SYSCS_IMPORT_DATA will accept column > names (instead of column indexes) in the 'COLUMNINDEXES' arguments. E.g., it > should be possible to indicate COLUMNINDEXES of '1,3,sales,5,'. This feature > will make it significantly easier to handle cases where the external input > files is extended to include additional columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6895) Add documentation for new SYSCS_IMPORT_TABLE_BULK, SYSCS_IMPORT_DATA_BULK procedures
[ https://issues.apache.org/jira/browse/DERBY-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387881#comment-15387881 ] Danoja Dias commented on DERBY-6895: I looked following links https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/ref/rrefimportdatabulk.html https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/ref/rrefimporttablebulk.html https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/ref/rrefimportdataproc.html https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/ref/rrefimportdataproclobs.html They are fine on the website. > Add documentation for new SYSCS_IMPORT_TABLE_BULK, SYSCS_IMPORT_DATA_BULK > procedures > > > Key: DERBY-6895 > URL: https://issues.apache.org/jira/browse/DERBY-6895 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: derby-6892-doc.zip, derby6892.diff, derby6895-doc.zip, > derby6895.diff, newderby-6895-doc.zip, newderby-6895.diff, > rrefimporttableprocwithheaderlines.html > > > The new system procedures proposed to be added by DERBY-4555 > need to be documented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[
https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danoja Dias updated DERBY-6852:
---
Attachment: derby_6852_2.diff
This patch works for the following cases.
GENERATED ... IDENTITY (CYCLE)
GENERATED ... IDENTITY (INCREMENT BY y, CYCLE)
GENERATED ... IDENTITY (INCREMENT BY y)
GENERATED ... IDENTITY (START WITH x, INCREMENT BY y, CYCLE)
GENERATED ... IDENTITY (START WITH x, INCREMENT BY y)
GENERATED ... IDENTITY (START WITH x)
But this patch doesn't work for
GENERATED ... IDENTITY (START WITH x, CYCLE)
The problem is in the method autoIncrementBeginEnd() in sqlgrammer.jj
{code}
autoIncrementInitial = exactNumber() [
autoIncrementIncrement = exactNumber() [ autoIncrementCycle =
whetherCycle() ] ]
{
autoIncrementInfo[QueryTreeNode.AUTOINCREMENT_START_INDEX] =
autoIncrementInitial;
autoIncrementInfo[QueryTreeNode.AUTOINCREMENT_INC_INDEX] =
autoIncrementIncrement;
autoIncrementInfo[QueryTreeNode.AUTOINCREMENT_CYCLE] =
autoIncrementCycle;
autoIncrementInfo[QueryTreeNode.AUTOINCREMENT_CREATE_MODIFY] =
ColumnDefinitionNode.CREATE_AUTOINCREMENT;
return;
}
{code}
In the above code, following part does not check or .
It checks only . How can we change it? I am not that familiar
with this javacc and grammar.
{code}
autoIncrementInitial = exactNumber() [
autoIncrementIncrement = exactNumber() [ autoIncrementCycle =
whetherCycle() ] ]
{code}
> Allow identity columns to cycle (as defined in SQL:2003)
>
>
> Key: DERBY-6852
> URL: https://issues.apache.org/jira/browse/DERBY-6852
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Reporter: Peter Hansson
>Assignee: Danoja Dias
> Attachments: derby-6852_1.diff, derby_6852_2.diff, script.sql
>
>
> Currently when an IDENTITY column reaches its maximum value it will produce
> an error.
> For tables that are used as 'transaction logs' or 'event logs' it often makes
> sense to let the table automatically start over with the first identity value
> again when the max is reached. This would be similar to the CYCLE option on
> Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used
> quite often for this purpose, I guess, perhaps even more than other RDBMSs.
> At the moment every developer have to program their own logic for this.
> I propose to introduce the CYCLE option.
> The idea of CYCLE is based on the assumption that there's been a prior
> cleanup in the table rows so that it will be possible to re-use ids that have
> been used previously. If that is not the case - and a rollover happens - then
> a duplicate value error will occur. In this sense it can be argued that the
> CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby
> users would possibly gladly accept such a bargain. In other words: This
> option will greatly enhance the usability of IDENTITY columns.
> The current implementation of IDENTITY columns SQL grammar in Derby is a
> subset of the SQL:2003 standard which is the first of the SQL standards to
> define IDENTITY columns. Interestingly the standard also defines the CYCLE
> option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003
> features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures]
> (scroll to T174).
> In other words: The proposal is simply to implement CYCLE as defined in
> SQL:2003.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DERBY-6895) Add documentation for new SYSCS_IMPORT_TABLE_BULK, SYSCS_IMPORT_DATA_BULK procedures
[ https://issues.apache.org/jira/browse/DERBY-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6895: --- Attachment: newderby-6895.diff newderby-6895-doc.zip Attaching newderby-6895.diff and a zip file of the corresponding generated output: newderby-6895-doc.zip. This patch adds a section to the Reference Manual describing SYSCS_UTIL.SYSCS_IMPORT_DATA_BULK, SYSCS_UTIL.SYSCS_IMPORT_TABLE_BULK system procedures and necessary changes to SYSCS_UTIL.SYSCS_IMPORT_DATA, SYSCS_UTIL.SYSCS_IMPORT_DATA_LOBS_FROM_EXTFILE system procedures. Touches the following files: M src/ref/refderby.ditamap A src/ref/rrefimportdatabulk.dita M src/ref/rrefimportdataproc.dita M src/ref/rrefimportdataproclobs.dita A src/ref/rrefimporttablebulk.dita > Add documentation for new SYSCS_IMPORT_TABLE_BULK, SYSCS_IMPORT_DATA_BULK > procedures > > > Key: DERBY-6895 > URL: https://issues.apache.org/jira/browse/DERBY-6895 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: derby-6892-doc.zip, derby6892.diff, derby6895-doc.zip, > derby6895.diff, newderby-6895-doc.zip, newderby-6895.diff, > rrefimporttableprocwithheaderlines.html > > > The new system procedures proposed to be added by DERBY-4555 > need to be documented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6895) Add documentation for new SYSCS_IMPORT_TABLE_BULK, SYSCS_IMPORT_DATA_BULK procedures
[ https://issues.apache.org/jira/browse/DERBY-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6895: --- Attachment: derby6895.diff derby6895-doc.zip Attaching derby6895.diff and a zip file of the corresponding generated output: derby6895-doc.zip. This patch adds a section to the Reference Manual describing SYSCS_UTIL.SYSCS_IMPORT_DATA_BULK system procedure. Touches the following files: M src/ref/refderby.ditamap A src/ref/rrefimportdataprocwithheaderlines.dita > Add documentation for new SYSCS_IMPORT_TABLE_BULK, SYSCS_IMPORT_DATA_BULK > procedures > > > Key: DERBY-6895 > URL: https://issues.apache.org/jira/browse/DERBY-6895 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: derby-6892-doc.zip, derby6892.diff, derby6895-doc.zip, > derby6895.diff, rrefimporttableprocwithheaderlines.html > > > The new system procedures proposed to be added by DERBY-4555 > need to be documented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6895) Add documentation for new SYSCS_IMPORT_TABLE_BULK, SYSCS_IMPORT_DATA_BULK procedures
[ https://issues.apache.org/jira/browse/DERBY-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15381231#comment-15381231 ] Danoja Dias commented on DERBY-6895: Yes it is worth adding it. What if we change the current description of COLUMNINDEXES like following. COLUMNINDEXES An input argument of type VARCHAR(32672) that specifies the indexes (numbered from 1 and separated by commas) of the input data fields to be imported. Passing a NULL value will use all of the input data fields in the file. This argument cannot identify column names as in SYSCS_UTIL.SYSCS_IMPORT_DATA_BULK procedure. Would it be confusing? > Add documentation for new SYSCS_IMPORT_TABLE_BULK, SYSCS_IMPORT_DATA_BULK > procedures > > > Key: DERBY-6895 > URL: https://issues.apache.org/jira/browse/DERBY-6895 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: derby-6892-doc.zip, derby6892.diff, > rrefimporttableprocwithheaderlines.html > > > The new system procedures proposed to be added by DERBY-4555 > need to be documented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6895) Add documentation for new SYSCS_IMPORT_TABLE_BULK, SYSCS_IMPORT_DATA_BULK procedures
[ https://issues.apache.org/jira/browse/DERBY-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6895: --- Attachment: derby6892.diff derby-6892-doc.zip Attaching derby-6892.diff and a zip file of the corresponding generated output: derby-6892-doc.zip. This patch adds a section to the Reference Manual describing SYSCS_UTIL.SYSCS_IMPORT_TABLE_BULK system procedure. Touches the following files: M src/ref/refderby.ditamap A src/ref/rrefimporttableprocwithheaderlines.dita > Add documentation for new SYSCS_IMPORT_TABLE_BULK, SYSCS_IMPORT_DATA_BULK > procedures > > > Key: DERBY-6895 > URL: https://issues.apache.org/jira/browse/DERBY-6895 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: derby-6892-doc.zip, derby6892.diff, > rrefimporttableprocwithheaderlines.html > > > The new system procedures proposed to be added by DERBY-4555 > need to be documented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6895) Add documentation for new SYSCS_IMPORT_TABLE_BULK, SYSCS_IMPORT_DATA_BULK procedures
[
https://issues.apache.org/jira/browse/DERBY-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15380841#comment-15380841
]
Danoja Dias commented on DERBY-6895:
Hi Bryan,
I followed the link you mentioned. When I run command ant html.ref after adding
my new file, It makes all other html files but not newly added one.
And also I don't get following part of the documentation. How to do this.
{quote}
If you are adding a new file, add a topicref for the new file to the ditamap.
You need to place the topicref in the ditamap exactly where you want the new
topic to appear in the manual.
{quote}
Thanks
> Add documentation for new SYSCS_IMPORT_TABLE_BULK, SYSCS_IMPORT_DATA_BULK
> procedures
>
>
> Key: DERBY-6895
> URL: https://issues.apache.org/jira/browse/DERBY-6895
> Project: Derby
> Issue Type: Sub-task
> Components: SQL
>Reporter: Bryan Pendleton
>Assignee: Danoja Dias
>Priority: Minor
> Attachments: rrefimporttableprocwithheaderlines.html
>
>
> The new system procedures proposed to be added by DERBY-4555
> need to be documented.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6894: --- Attachment: EndofLineError.diff I added a new method to importReadData.java and the tests. it solves this problem. I added the new method since it avoids the risk of having issues by editing existing ignoreFirstRow() method. > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6894.diff, EndofLineError.diff, NewDerby6894.diff, > NewDerby6894_2.diff, NewDerby6894_3.diff, noHeaderLines.csv, petlist.csv, > readHeadersLoadError.diff, repro.java, repro.java > > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379519#comment-15379519 ] Danoja Dias commented on DERBY-6894: Hi Bryan, Yes it seems like a awesome idea. Thanks for suggesting it. > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6894.diff, NewDerby6894.diff, NewDerby6894_2.diff, > NewDerby6894_3.diff, noHeaderLines.csv, petlist.csv, > readHeadersLoadError.diff, repro.java, repro.java > > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379268#comment-15379268 ] Danoja Dias commented on DERBY-6894: Yes, I think this is ready to submit. > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6894.diff, NewDerby6894.diff, NewDerby6894_2.diff, > NewDerby6894_3.diff, noHeaderLines.csv, petlist.csv, repro.java, repro.java > > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6894: --- Attachment: NewDerby6894_3.diff I added all tests and one more message. All tests are clean. I think we have to widen the SQLException to Exception. All other methods that creates objects of importReadData class throws Exception. Give me any suggestion for this. > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6894.diff, NewDerby6894.diff, NewDerby6894_2.diff, > NewDerby6894_3.diff, noHeaderLines.csv, petlist.csv, repro.java, repro.java > > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15376838#comment-15376838 ] Danoja Dias commented on DERBY-6894: Specify skip == 4 and columnindexes == "Pet Name Rover",2,3 Specify skip == 4 and columnindexes == 1,2,"Age 4" Specify skip == 4 and columnindexes == 1,"Kind of Animal Dog",3 For these three test cases we cannot do anything to notify user even if we change the table, since it gives 4 to skip argument. > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6894.diff, NewDerby6894.diff, NewDerby6894_2.diff, > noHeaderLines.csv, petlist.csv, repro.java, repro.java > > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15376287#comment-15376287 ] Danoja Dias commented on DERBY-6894: Hi Bryan, Here 4th and 5th tests results a set as follows. Name, of,null null, Animal,null Rover, Dog,4 Spot, cat,2 Squawky, Parrot,37 If the data type of the table columns doesn't match with header names it will give an error. It means if table column types are not varchar, then it will produce an error. If not we cannot identify there is an error. User should give the correct values. Thanks > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6894.diff, NewDerby6894.diff, NewDerby6894_2.diff, > noHeaderLines.csv, petlist.csv, repro.java, repro.java > > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[
https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15369934#comment-15369934
]
Danoja Dias commented on DERBY-6894:
{quote}
I'm a little uncomfortable about needing to widen the exception
signature of methods in other parts of the code. Is this caused
by the readHeaders() method throwing Exception?
{quote}
Yes. It is the reason for it. I tried not doing that. I'll try again.
> Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns
> by name
> -
>
> Key: DERBY-6894
> URL: https://issues.apache.org/jira/browse/DERBY-6894
> Project: Derby
> Issue Type: Sub-task
> Components: SQL
>Reporter: Bryan Pendleton
>Assignee: Danoja Dias
>Priority: Minor
> Attachments: Derby-6894.diff, NewDerby6894.diff, NewDerby6894_2.diff,
> noHeaderLines.csv, petlist.csv, repro.java, repro.java
>
>
> To ease maintainability and legibility of client programs, it would be
> nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also
> SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES
> argument by column *NAME*, as well as by index *NUMBER*.
> So, for example, a valid COLUMNINDEXES specification might be:
> '1,3,LastName,FirstName,7'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6894: --- Attachment: NewDerby6894_2.diff I added new error message and new tests. Should I add any more tests. Newly added Tests are clean. I changed some SQLExceptions into Exceptions in several methods. In the documentation about adding new error message the steps are given. I think the example for 4th step should be changed. Thanks. > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6894.diff, NewDerby6894.diff, NewDerby6894_2.diff, > noHeaderLines.csv, petlist.csv, repro.java, repro.java > > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[
https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15369221#comment-15369221
]
Danoja Dias commented on DERBY-6894:
1.)
It should be like this.
{code}
vtiColumnNames.add(vtiColumnPrefix +cIndex);
{code}
2.) Yes. I have an Experience in DERBY-3181 too. I'll look at the documentation
too.
> Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns
> by name
> -
>
> Key: DERBY-6894
> URL: https://issues.apache.org/jira/browse/DERBY-6894
> Project: Derby
> Issue Type: Sub-task
> Components: SQL
>Reporter: Bryan Pendleton
>Assignee: Danoja Dias
>Priority: Minor
> Attachments: Derby-6894.diff, NewDerby6894.diff, noHeaderLines.csv,
> petlist.csv, repro.java, repro.java
>
>
> To ease maintainability and legibility of client programs, it would be
> nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also
> SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES
> argument by column *NAME*, as well as by index *NUMBER*.
> So, for example, a valid COLUMNINDEXES specification might be:
> '1,3,LastName,FirstName,7'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[
https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15369210#comment-15369210
]
Danoja Dias commented on DERBY-6894:
Hi Bryan,
{quote}
if 'skip > 0', open the input file, read the first
'skip' number of lines, parse the column structure, and construct an array of
the column headers, then close the input file and return the headers array
{quote}
Yes, this is the exact thing this patch does.
In ImportReadData.java file,
openFile() , closeStream() functions are called several times.
Whenever the ImportReadData.java class is used, opening file and closing file
happens several times. Therefore would it be a issue?
> Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns
> by name
> -
>
> Key: DERBY-6894
> URL: https://issues.apache.org/jira/browse/DERBY-6894
> Project: Derby
> Issue Type: Sub-task
> Components: SQL
>Reporter: Bryan Pendleton
>Assignee: Danoja Dias
>Priority: Minor
> Attachments: Derby-6894.diff, NewDerby6894.diff, noHeaderLines.csv,
> petlist.csv, repro.java, repro.java
>
>
> To ease maintainability and legibility of client programs, it would be
> nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also
> SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES
> argument by column *NAME*, as well as by index *NUMBER*.
> So, for example, a valid COLUMNINDEXES specification might be:
> '1,3,LastName,FirstName,7'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6894: --- Attachment: NewDerby6894.diff petlist.csv repro.java I added the new patch and it works fine for newly added repro.java with petlist.csv. I think new exception messages must be thrown where I have commented. Need to write new tests. > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6894.diff, NewDerby6894.diff, noHeaderLines.csv, > petlist.csv, repro.java, repro.java > > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6893) Create new SYSCS_IMPORT_DATA_BULK procedure
[ https://issues.apache.org/jira/browse/DERBY-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366204#comment-15366204 ] Danoja Dias commented on DERBY-6893: I added new updated patch > Create new SYSCS_IMPORT_DATA_BULK procedure > --- > > Key: DERBY-6893 > URL: https://issues.apache.org/jira/browse/DERBY-6893 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6893.diff, UpdatedDerby6893.diff > > > As a sub-task of DERBY-4555, we propose to create a new system > procedure SYSCS_IMPORT_DATA_BULK, which supports all the > functionality of SYSCS_IMPORT_DATA, but additionally supports detecting and > skipping multi-line column headers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[ https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15364823#comment-15364823 ] Danoja Dias commented on DERBY-6852: After changing the SQL grammar to pass logic it will be like this. GENERATED ... IDENTITY (START WITH 1, INCREMENT BY 1, CYCLE) This should be implemented in SQLParser.java > Allow identity columns to cycle (as defined in SQL:2003) > > > Key: DERBY-6852 > URL: https://issues.apache.org/jira/browse/DERBY-6852 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Peter Hansson >Assignee: Danoja Dias > Attachments: derby-6852_1.diff, script.sql > > > Currently when an IDENTITY column reaches its maximum value it will produce > an error. > For tables that are used as 'transaction logs' or 'event logs' it often makes > sense to let the table automatically start over with the first identity value > again when the max is reached. This would be similar to the CYCLE option on > Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used > quite often for this purpose, I guess, perhaps even more than other RDBMSs. > At the moment every developer have to program their own logic for this. > I propose to introduce the CYCLE option. > The idea of CYCLE is based on the assumption that there's been a prior > cleanup in the table rows so that it will be possible to re-use ids that have > been used previously. If that is not the case - and a rollover happens - then > a duplicate value error will occur. In this sense it can be argued that the > CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby > users would possibly gladly accept such a bargain. In other words: This > option will greatly enhance the usability of IDENTITY columns. > The current implementation of IDENTITY columns SQL grammar in Derby is a > subset of the SQL:2003 standard which is the first of the SQL standards to > define IDENTITY columns. Interestingly the standard also defines the CYCLE > option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003 > features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures] > (scroll to T174). > In other words: The proposal is simply to implement CYCLE as defined in > SQL:2003. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[ https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361690#comment-15361690 ] Danoja Dias commented on DERBY-6852: Hi Bryan, Yes it works. I was in a misunderstanding that identity column should be unique. I think we have finished the first part. Thanks. > Allow identity columns to cycle (as defined in SQL:2003) > > > Key: DERBY-6852 > URL: https://issues.apache.org/jira/browse/DERBY-6852 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Peter Hansson >Assignee: Danoja Dias > Attachments: derby-6852_1.diff, script.sql > > > Currently when an IDENTITY column reaches its maximum value it will produce > an error. > For tables that are used as 'transaction logs' or 'event logs' it often makes > sense to let the table automatically start over with the first identity value > again when the max is reached. This would be similar to the CYCLE option on > Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used > quite often for this purpose, I guess, perhaps even more than other RDBMSs. > At the moment every developer have to program their own logic for this. > I propose to introduce the CYCLE option. > The idea of CYCLE is based on the assumption that there's been a prior > cleanup in the table rows so that it will be possible to re-use ids that have > been used previously. If that is not the case - and a rollover happens - then > a duplicate value error will occur. In this sense it can be argued that the > CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby > users would possibly gladly accept such a bargain. In other words: This > option will greatly enhance the usability of IDENTITY columns. > The current implementation of IDENTITY columns SQL grammar in Derby is a > subset of the SQL:2003 standard which is the first of the SQL standards to > define IDENTITY columns. Interestingly the standard also defines the CYCLE > option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003 > features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures] > (scroll to T174). > In other words: The proposal is simply to implement CYCLE as defined in > SQL:2003. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6893) Create new SYSCS_IMPORT_DATA_BULK procedure
[ https://issues.apache.org/jira/browse/DERBY-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6893: --- Attachment: UpdatedDerby6893.diff > Create new SYSCS_IMPORT_DATA_BULK procedure > --- > > Key: DERBY-6893 > URL: https://issues.apache.org/jira/browse/DERBY-6893 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6893.diff, UpdatedDerby6893.diff > > > As a sub-task of DERBY-4555, we propose to create a new system > procedure SYSCS_IMPORT_DATA_BULK, which supports all the > functionality of SYSCS_IMPORT_DATA, but additionally supports detecting and > skipping multi-line column headers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361014#comment-15361014 ] Danoja Dias commented on DERBY-6894: Yes, I got it. I was not that familiar with this system procedure. Both column names of the file and the table are independent from each other. I had totally misunderstood the process. Thanks for the detailed explanation. > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6894.diff, noHeaderLines.csv, repro.java > > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360626#comment-15360626 ] Danoja Dias commented on DERBY-6894: I meant that the names should be same in the file and the table. the difference here is the case and the white spaces of the column name > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6894.diff, noHeaderLines.csv, repro.java > > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360624#comment-15360624 ] Danoja Dias commented on DERBY-6894: Yes Bryan, I will change the patch to support this. I am the one who misunderstood the process. One more clarification, Here The column "Pet Name" in the file is the same column in "PETNAME" in the table. right? > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6894.diff, noHeaderLines.csv, repro.java > > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6893) Create new SYSCS_IMPORT_DATA_BULK procedure
[ https://issues.apache.org/jira/browse/DERBY-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6893: --- Attachment: Derby-6893.diff > Create new SYSCS_IMPORT_DATA_BULK procedure > --- > > Key: DERBY-6893 > URL: https://issues.apache.org/jira/browse/DERBY-6893 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6893.diff > > > As a sub-task of DERBY-4555, we propose to create a new system > procedure SYSCS_IMPORT_DATA_BULK, which supports all the > functionality of SYSCS_IMPORT_DATA, but additionally supports detecting and > skipping multi-line column headers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360446#comment-15360446 ] Danoja Dias commented on DERBY-6894: Hi Bryan, No this while loop is not supposed to run more than once. Therefore it should be if condition not a while loop. I will add the new patch with the tests. All existing tests are clean. This is the list of cases that I came up with. Do you have any suggesions to include or exclude tests? I think we should add these tests to ImportExportProcedureTest.java For a table like this A(petName varchar(50),3 varchar(50) , age int) 1.) pass cases Columns by name and indexes CALL SYSCS_UTIL.SYSCS_IMPORT_DATA(null, 'A', null ,'1,2,\"AGE\"', 'pet.dat', null, null, null,0) Columns by only names CALL SYSCS_UTIL.SYSCS_IMPORT_DATA(null, 'A', null ,'\"PETNAME\",\"3\",\"AGE\"', 'pet.dat', null, null, null,0) Columns by only names and changing the order of columns CALL SYSCS_UTIL.SYSCS_IMPORT_DATA(null, 'A', null ,'\"AGE\",\"PETNAME\",\"3\"', 'pet.dat', null, null, null,0) Only two columns out of four by name CALL SYSCS_UTIL.SYSCS_IMPORT_DATA(null, 'A', null ,'\"PETNAME\",\"KINDOFANIMAL\"', 'pet.dat', null, null, null,0) 2.) Fail cases not giving capital letters. CALL SYSCS_UTIL.SYSCS_IMPORT_DATA(null, 'A', null ,'\"petname\",\"3\",\"AGE\"', 'pet.dat', null, null, null,0) Give column name without '"' mark. Need to get the column named 3, but gets the index 3 column. CALL SYSCS_UTIL.SYSCS_IMPORT_DATA(null, 'A', null ,'3', 'pet.dat', null, null, null,0) Thanks > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6894.diff, noHeaderLines.csv, repro.java > > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[ https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360399#comment-15360399 ] Danoja Dias commented on DERBY-6852: When reusing the ids that have been used previously, a duplicate value error should occur. The above patch passes the DERBY-6550 test case. I tried using restart value, not the minimum value and tested the case in DERBY-6550. It does not give duplicate value error. I am trying to figure out how it should be done. Sorry for the confusing explanations. > Allow identity columns to cycle (as defined in SQL:2003) > > > Key: DERBY-6852 > URL: https://issues.apache.org/jira/browse/DERBY-6852 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Peter Hansson >Assignee: Danoja Dias > Attachments: derby-6852_1.diff > > > Currently when an IDENTITY column reaches its maximum value it will produce > an error. > For tables that are used as 'transaction logs' or 'event logs' it often makes > sense to let the table automatically start over with the first identity value > again when the max is reached. This would be similar to the CYCLE option on > Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used > quite often for this purpose, I guess, perhaps even more than other RDBMSs. > At the moment every developer have to program their own logic for this. > I propose to introduce the CYCLE option. > The idea of CYCLE is based on the assumption that there's been a prior > cleanup in the table rows so that it will be possible to re-use ids that have > been used previously. If that is not the case - and a rollover happens - then > a duplicate value error will occur. In this sense it can be argued that the > CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby > users would possibly gladly accept such a bargain. In other words: This > option will greatly enhance the usability of IDENTITY columns. > The current implementation of IDENTITY columns SQL grammar in Derby is a > subset of the SQL:2003 standard which is the first of the SQL standards to > define IDENTITY columns. Interestingly the standard also defines the CYCLE > option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003 > features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures] > (scroll to T174). > In other words: The proposal is simply to implement CYCLE as defined in > SQL:2003. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6852) Allow identity columns to cycle (as defined in SQL:2003)
[
https://issues.apache.org/jira/browse/DERBY-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danoja Dias updated DERBY-6852:
---
Attachment: derby-6852_1.diff
{quote}
1) Finding and changing the code where an IDENTITY column creates
an underlying SEQUENCE object, so that the code can create a
SEQUENCE with CYCLE option. Experimentally, we could make
this change automatic, just to prove that it works, and makes
the DERBY-6550 test case pass, but before commit we'd want to
make this code be driven by information passed from the compiler.
I think this is in CreateTableConstantAction
2) Changing the Derby SQL Grammar and parsing logic so that it
can recognize the CYCLE keyword in the CREATE TABLE statement,
and use the presence (or absence) of that keyword to control
the code that we worked on in the first step.
3) Writing various new test cases to test all the code we wrote in steps (1)
and (2)
4) Updating the documentation to reflect the new feature.
{quote}
With this patch I tried to do the first part of the tasks above.
But not the duplicate value error. I found that it is implemented in
IndexChanger.java and I'm trying to figure out how it works. Any help to
figure this out will be helpful.
> Allow identity columns to cycle (as defined in SQL:2003)
>
>
> Key: DERBY-6852
> URL: https://issues.apache.org/jira/browse/DERBY-6852
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Reporter: Peter Hansson
>Assignee: Danoja Dias
> Attachments: derby-6852_1.diff
>
>
> Currently when an IDENTITY column reaches its maximum value it will produce
> an error.
> For tables that are used as 'transaction logs' or 'event logs' it often makes
> sense to let the table automatically start over with the first identity value
> again when the max is reached. This would be similar to the CYCLE option on
> Oracle's SEQUENCE and as defined in SQL:2003. And Derby is probably used
> quite often for this purpose, I guess, perhaps even more than other RDBMSs.
> At the moment every developer have to program their own logic for this.
> I propose to introduce the CYCLE option.
> The idea of CYCLE is based on the assumption that there's been a prior
> cleanup in the table rows so that it will be possible to re-use ids that have
> been used previously. If that is not the case - and a rollover happens - then
> a duplicate value error will occur. In this sense it can be argued that the
> CYCLE option will trade a _certain_ error for a _potential_ error. Most Derby
> users would possibly gladly accept such a bargain. In other words: This
> option will greatly enhance the usability of IDENTITY columns.
> The current implementation of IDENTITY columns SQL grammar in Derby is a
> subset of the SQL:2003 standard which is the first of the SQL standards to
> define IDENTITY columns. Interestingly the standard also defines the CYCLE
> option but this was never implemented in Derby. Also see [SQL-99 and SQL-2003
> features mapped to Derby|https://wiki.apache.org/db-derby/SQLvsDerbyFeatures]
> (scroll to T174).
> In other words: The proposal is simply to implement CYCLE as defined in
> SQL:2003.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DERBY-6892) Create new SYSCS_IMPORT_TABLE_BULK procedure
[ https://issues.apache.org/jira/browse/DERBY-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354190#comment-15354190 ] Danoja Dias commented on DERBY-6892: Hi Bryan, It looks correct to me. Thanks. > Create new SYSCS_IMPORT_TABLE_BULK procedure > > > Key: DERBY-6892 > URL: https://issues.apache.org/jira/browse/DERBY-6892 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6892-whitespaceCleanup.diff, Derby-6892.diff, > Updated-Derby-6892.diff, addNewSystemProcedure.diff > > > As a sub-task of DERBY-4555, we propose to create a new > system procedure, SYSCS_IMPORT_TABLE_BULK, which supports > all the functionality of SYSCS_IMPORT_TABLE, but additionally supports > skipping multi-line column headers in the input file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6894: --- Attachment: noHeaderLines.csv repro.java Derby-6894.diff This patch works fine for repro.java Names must be given in uppercase letters like giving values to INSERTCOLUMNS in SYSCS_UTIL.SYSCS_IMPORT_DATA procedure. > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6894.diff, noHeaderLines.csv, repro.java > > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15350744#comment-15350744 ] Danoja Dias edited comment on DERBY-6894 at 6/28/16 4:57 PM: - SYSCS_UTIL.SYSCS_IMPORT_DATA (SCHEMANAME,TABLENAME, INSERTCOLUMNS,COLUMNINDEXES,FILENAME, COLUMNDELIMITER ,CHARACTERDELIMITER,CODESET , REPLACE) Here how to give values to INSERTCOLUMNS argument. I tried like follows. CALL SYSCS_UTIL.SYSCS_IMPORT_DATA(null, 'A', 'petName,age' ,'1,3', 'noHeaderLines.csv', null, null, null,0) create table statement is like this. create table A(petName varchar(50), age int) But this gives me an Exception saying "There is no column named: petName" I searched for an example in the Internet. But I couldn't find it. This will be a clue to solve this issue. .. UPDATE : I found how to give arguments values to the argument INSERTCOLUMNS. The names of this argument should be Uppercase letters like this. CALL SYSCS_UTIL.SYSCS_IMPORT_DATA(null, 'A', 'PETNAME,AGE' ,'1,3', 'noHeaderLines.csv', null, null, null,0) was (Author: dnj): SYSCS_UTIL.SYSCS_IMPORT_DATA (SCHEMANAME,TABLENAME, INSERTCOLUMNS,COLUMNINDEXES,FILENAME, COLUMNDELIMITER ,CHARACTERDELIMITER,CODESET , REPLACE) Here how to give values to INSERTCOLUMNS argument. I tried like follows. CALL SYSCS_UTIL.SYSCS_IMPORT_DATA(null, 'A', 'petName,age' ,'1,3', 'noHeaderLines.csv', null, null, null,0) create table statement is like this. create table A(petName varchar(50), age int) But this gives me an Exception saying "There is no column named: petName" I searched for an example in the Internet. But I couldn't find it. This will be a clue to solve this issue. > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6892) Create new SYSCS_IMPORT_TABLE_BULK procedure
[ https://issues.apache.org/jira/browse/DERBY-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6892: --- Attachment: Updated-Derby-6892.diff I changed the method signature and others. > Create new SYSCS_IMPORT_TABLE_BULK procedure > > > Key: DERBY-6892 > URL: https://issues.apache.org/jira/browse/DERBY-6892 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6892.diff, Updated-Derby-6892.diff, > addNewSystemProcedure.diff > > > As a sub-task of DERBY-4555, we propose to create a new > system procedure, SYSCS_IMPORT_TABLE_BULK, which supports > all the functionality of SYSCS_IMPORT_TABLE, but additionally supports > skipping multi-line column headers in the input file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15350746#comment-15350746 ] Danoja Dias commented on DERBY-6894: Yes, It will be a good approach. Thanks. > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15350744#comment-15350744 ] Danoja Dias commented on DERBY-6894: SYSCS_UTIL.SYSCS_IMPORT_DATA (SCHEMANAME,TABLENAME, INSERTCOLUMNS,COLUMNINDEXES,FILENAME, COLUMNDELIMITER ,CHARACTERDELIMITER,CODESET , REPLACE) Here how to give values to INSERTCOLUMNS argument. I tried like follows. CALL SYSCS_UTIL.SYSCS_IMPORT_DATA(null, 'A', 'petName,age' ,'1,3', 'noHeaderLines.csv', null, null, null,0) create table statement is like this. create table A(petName varchar(50), age int) But this gives me an Exception saying "There is no column named: petName" I searched for an example in the Internet. But I couldn't find it. This will be a clue to solve this issue. > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6892) Create new SYSCS_IMPORT_TABLE_BULK procedure
[ https://issues.apache.org/jira/browse/DERBY-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15350410#comment-15350410 ] Danoja Dias commented on DERBY-6892: Are there any more improvements to do for this issue? > Create new SYSCS_IMPORT_TABLE_BULK procedure > > > Key: DERBY-6892 > URL: https://issues.apache.org/jira/browse/DERBY-6892 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6892.diff, addNewSystemProcedure.diff > > > As a sub-task of DERBY-4555, we propose to create a new > system procedure, SYSCS_IMPORT_TABLE_BULK, which supports > all the functionality of SYSCS_IMPORT_TABLE, but additionally supports > skipping multi-line column headers in the input file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15350287#comment-15350287 ] Danoja Dias commented on DERBY-6894: As Bryan has raised the problem about this issue in Derby-4555 what happens if CSV file has multi line headers? > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6895) Add documentation for new SYSCS_IMPORT_TABLE_BULK, SYSCS_IMPORT_DATA_BULK procedures
[ https://issues.apache.org/jira/browse/DERBY-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6895: --- Attachment: rrefimporttableprocwithheaderlines.html I tried to document the SYSCS_IMPORT_TABLE_BULK procedure. I think there are more to change and write. Could you please guide me for it. Thanks > Add documentation for new SYSCS_IMPORT_TABLE_BULK, SYSCS_IMPORT_DATA_BULK > procedures > > > Key: DERBY-6895 > URL: https://issues.apache.org/jira/browse/DERBY-6895 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: rrefimporttableprocwithheaderlines.html > > > The new system procedures proposed to be added by DERBY-4555 > need to be documented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6892) Create new SYSCS_IMPORT_TABLE_BULK procedure
[ https://issues.apache.org/jira/browse/DERBY-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15350265#comment-15350265 ] Danoja Dias commented on DERBY-6892: SYSCS_IMPORT_TABLE system procedure is now modified as SYSCS_IMPORT_TABLE_BULK to accept csv files skipping the column header lines in the input file. Next, this improvement is to be done for SYSCS_IMPORT_DATA procedure. > Create new SYSCS_IMPORT_TABLE_BULK procedure > > > Key: DERBY-6892 > URL: https://issues.apache.org/jira/browse/DERBY-6892 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6892.diff, addNewSystemProcedure.diff > > > As a sub-task of DERBY-4555, we propose to create a new > system procedure, SYSCS_IMPORT_TABLE_BULK, which supports > all the functionality of SYSCS_IMPORT_TABLE, but additionally supports > skipping multi-line column headers in the input file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6894) Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns by name
[ https://issues.apache.org/jira/browse/DERBY-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15350101#comment-15350101 ] Danoja Dias commented on DERBY-6894: It is a good point that we didn't think of. If header has column names which are numbers, then no way to identify whether it is a name or a number. Bryan, What do you think? Is there a way to proceed ? Thanks > Enhance COLUMNINDEXES parsing for SYSCS_IMPORT_DATA_BULK to recognize columns > by name > - > > Key: DERBY-6894 > URL: https://issues.apache.org/jira/browse/DERBY-6894 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > > To ease maintainability and legibility of client programs, it would be > nice if callers of SYSCS_IMPORT_DATA_BULK (and possibly also > SYSCS_IMPORT_DATA) could refer to columns in the COLUMNINDEXES > argument by column *NAME*, as well as by index *NUMBER*. > So, for example, a valid COLUMNINDEXES specification might be: > '1,3,LastName,FirstName,7' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6892) Create new SYSCS_IMPORT_TABLE_BULK procedure
[ https://issues.apache.org/jira/browse/DERBY-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danoja Dias updated DERBY-6892: --- Attachment: Derby-6892.diff > Create new SYSCS_IMPORT_TABLE_BULK procedure > > > Key: DERBY-6892 > URL: https://issues.apache.org/jira/browse/DERBY-6892 > Project: Derby > Issue Type: Sub-task > Components: SQL >Reporter: Bryan Pendleton >Assignee: Danoja Dias >Priority: Minor > Attachments: Derby-6892.diff, addNewSystemProcedure.diff > > > As a sub-task of DERBY-4555, we propose to create a new > system procedure, SYSCS_IMPORT_TABLE_BULK, which supports > all the functionality of SYSCS_IMPORT_TABLE, but additionally supports > skipping multi-line column headers in the input file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
