[jira] Commented: (DERBY-3189) Replication: Add connection url command options for starting and stopping master
[ https://issues.apache.org/jira/browse/DERBY-3189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560784#action_12560784 ] V.Narayanan commented on DERBY-3189: RawStore#MASTER_DB needs to be initialized in RawStore#startReplicationMaster. MasterController uses this property to set dbname. Replication: Add connection url command options for starting and stopping master Key: DERBY-3189 URL: https://issues.apache.org/jira/browse/DERBY-3189 Project: Derby Issue Type: Sub-task Components: JDBC Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: V.Narayanan Attachments: derby-3189-1a.diff, derby-3189-1a.stat, StopMaster_impl_3189_v1.diff, StopMaster_impl_3189_v1.stat, StopMaster_impl_3189_v2.diff, StopMaster_impl_3189_v2.diff, StopMaster_impl_3189_v2.stat, StopMaster_impl_3189_v2.stat, StopMaster_impl_3189_v3.diff, StopMaster_impl_3189_v3.stat Add commands to start and stop the replication master using properties or connection url. Example: 'jdbc:derby:hostmasterdb;startMaster=true'; 'jdbc:derby:hostmasterdb;stopMaster=true'; Connection url options that must be recognized: startMaster=true stopMaster=true slaveHost=host (required) slavePort=port (optional, defaults to 8001) See functional specification on Derby-2872 for further details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3205) Replication: Add connection url command options for starting, stopping slave and for failover
[ https://issues.apache.org/jira/browse/DERBY-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3205: --- Summary: Replication: Add connection url command options for starting, stopping slave and for failover (was: Replication: Add connection url command options for starting and stopping slave) This patch has been used to submit patches for the failover url also hence updating the issue description to reflect the same. Replication: Add connection url command options for starting, stopping slave and for failover - Key: DERBY-3205 URL: https://issues.apache.org/jira/browse/DERBY-3205 Project: Derby Issue Type: Sub-task Components: JDBC Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: V.Narayanan Attachments: derby-3205_startslave_dontcommit.diff, derby-3205_startslave_dontcommit.stat, failover_impl_3205_NotForCommit_v1.diff, failover_impl_3205_NotForCommit_v1.stat, startSlave_1a.diff, startSlave_1a.stat, startSlave_1b.diff, startSlave_1b.stat, startSlave_1c.diff, startSlave_1d.diff, StopSlave_impl_3205_NotForCommit_v1.diff, StopSlave_impl_3205_NotForCommit_v1.stat Add commands to start and stop the replication slave using properties or connection url. Example: 'jdbc:derby:hostdbname;startSlave=true'; 'jdbc:derby:hostdbname;stopSlave=true'; 'jdbc:derby:hostdbname;failover=true; Connection url options that must be recognized: startSlave=true stopSlave=true failover=true slaveHost=host (optional, defaults to localhost) (only for startSlave) slavePort=port (optional, defaults to 8001) (only for startSlave) See functional specification on Derby-2872 for further details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3205) Replication: Add connection url command options for starting, stopping slave and for failover
[ https://issues.apache.org/jira/browse/DERBY-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560786#action_12560786 ] V.Narayanan commented on DERBY-3205: I have been trying to integrate the preliminary failover patch here and the failover implementation patch submitted as part of Derby-3254 and I found a few issues in both patches. 1) The patch failover_impl_3205_NotForCommit_v1.diff needs to use Monitor#findServiceModule instead of Monitor#bootServiceModule in RawStore#failover(). I shall enumerate the issues found in the failover implementation in the jira for that issue. Replication: Add connection url command options for starting, stopping slave and for failover - Key: DERBY-3205 URL: https://issues.apache.org/jira/browse/DERBY-3205 Project: Derby Issue Type: Sub-task Components: JDBC Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: V.Narayanan Attachments: derby-3205_startslave_dontcommit.diff, derby-3205_startslave_dontcommit.stat, failover_impl_3205_NotForCommit_v1.diff, failover_impl_3205_NotForCommit_v1.stat, startSlave_1a.diff, startSlave_1a.stat, startSlave_1b.diff, startSlave_1b.stat, startSlave_1c.diff, startSlave_1d.diff, StopSlave_impl_3205_NotForCommit_v1.diff, StopSlave_impl_3205_NotForCommit_v1.stat Add commands to start and stop the replication slave using properties or connection url. Example: 'jdbc:derby:hostdbname;startSlave=true'; 'jdbc:derby:hostdbname;stopSlave=true'; 'jdbc:derby:hostdbname;failover=true; Connection url options that must be recognized: startSlave=true stopSlave=true failover=true slaveHost=host (optional, defaults to localhost) (only for startSlave) slavePort=port (optional, defaults to 8001) (only for startSlave) See functional specification on Derby-2872 for further details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3254) Implement the replication failover functionality
[ https://issues.apache.org/jira/browse/DERBY-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560787#action_12560787 ] V.Narayanan commented on DERBY-3254: 1) The exception being thrown upon successful failover in MasterController#startFailover needs to moved outside the try catch block. 2) If failover is successful AsynchonousLogShipper#stopLogShippment needs to be called to terminate the log shipper thread. Implement the replication failover functionality Key: DERBY-3254 URL: https://issues.apache.org/jira/browse/DERBY-3254 Project: Derby Issue Type: Sub-task Components: Replication Reporter: V.Narayanan Assignee: V.Narayanan Attachments: failover_impl_notforcommit.diff, failover_impl_notforcommit.stat, failover_impl_v1.diff, failover_impl_v1.stat, failover_impl_v2.diff, failover_impl_v2.stat, failover_impl_v3.diff, failover_impl_v3.stat, failover_impl_v4.diff, failover_impl_v4.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Getting the LangaugeConnectionContext
I need to get the langaugeconnectioncontext. I presume it can be done through this: LangaugeConnectionContext=activation.getLangaugeConnectionContext() But How do I create an Activation object? Are there any implemented classes for Activation interface..?? I am doing this since it forms a part of the code to get the type of an object. Please get me some help as soon as possible..
Re: Getting the LangaugeConnectionContext
Hi Jazarine, I'm assuming you need to get the LCC once you are in the execute phase, and in a class implementing ResultSet. All the different ResultSet implementations in org.apache.derby.impl.sql.execute get an activation supplied to their constructor either directly, or through its source/child ResultSet. It should hence be available either: - as a member of the given ResultSet class - though the ResultSets source/child ResultSet - through getLanguageConnectionContext() - or through getActivation().getLanguageConnectionContext() depending on the ResultSet class implementation you are in. It could be beneficial to have a look around ProjectRestrictNodeResultSet, the top-most ResultSet for a SELECT qry, and see how it's fetched/used? Activations are created/built with an ActivationClassBuilder and is populated during the bytecode generation phase. You can see one example of how the ActivationClassBuilder is used in ProjectRestrictNode.generateMinion() in org.apache.derby.impl.sql.compile. ProjectRestrictNode is the node generating the ProjectRestrictNodeResultSet (and a few others for the sake of correctness). Generally we push objects to the stack, then call to ActivationClassBuilder to push generation of the correct type of ResultSet on the stack. This is where the actual Activation object is created, and as previously stated it's often pushed as a parameter to the ResultSet constructor. Once code generation is completed, we start executing the generated bytecode. Someone with a little more knowledge of the details may want to explain this further, or correct me, if necessary? :) Hope this helps you figure it out :) Thomas Jazarine Jamal wrote: I need to get the langaugeconnectioncontext. I presume it can be done through this: LangaugeConnectionContext=activation.getLangaugeConnectionContext() But How do I create an Activation object? Are there any implemented classes for Activation interface..?? I am doing this since it forms a part of the code to get the type of an object. Please get me some help as soon as possible..
Regression Test Report - Daily 613415 - Sun DBTG
[Auto-generated mail] *Daily* 613415/2008-01-19 18:01:00 MET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 0273273 072.12% derbyall 01015710157 0 1551.10% suitesAll linN+1 0273273 0 103.29% derbyall 01015710157 0 111.08% suitesAll sles 1273272 070.74% derbyall 01015710157 0 849.39% suitesAll sol 0273273 076.13% derbyall 01015710157 0 1351.86% suitesAll solN+1 0273273 097.25% derbyall 01015710157 0 197.12% suitesAll sparc 0273273 066.89% derbyall 01015710157 0 355.51% suitesAll vista 0273273 092.89% derbyall 091359135 066.48% suitesAll w2003 0273273 094.91% derbyall 091359135 0 131.16% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-613415.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/613415_bySig.html *Jvm: 1.5* lin 0274274 071.51% derbyall 084398439 0 874.52% suitesAll linN+1 1274273 0 100.44% derbyall 084398439 0 117.63% suitesAll sles 0274274 070.09% derbyall 084398439 0 570.78% suitesAll sol 0274274 078.39% derbyall 084398439 0 838.75% suitesAll solN+1 0274274 088.05% derbyall 084398439 0 792.60% suitesAll sparc 0274274 066.79% derbyall 084398439 0 684.52% suitesAll vista 0274274 071.30% derbyall 074177417 0 401.92% suitesAll w2003 0274274 074.03% derbyall 074177417 0 257.78% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-613415.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/613415_bySig.html *Jvm: 1.4* lin 0271271 272.93% derbyall 083878387 0 798.68% suitesAll linN+1 1271270 292.54% derbyall 083878387 0 116.43% suitesAll sles 0271271 270.57% derbyall 083878387 0 523.34% suitesAll sol 0271271 277.55% derbyall 083878387 0 673.37% suitesAll solN+1 0271271 289.33% derbyall 083878387 0 741.71% suitesAll sparc 0271271 266.87% derbyall 083878387 0 697.18% suitesAll vista 0271271 271.16% derbyall 073657365 0 386.20% suitesAll w2003 0271271 275.19% derbyall 073667366 0 245.95% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-613415.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/613415_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/613415.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (12 issues) Subscriber: derby-dev Key Summary DERBY-3254 Implement the replication failover functionality https://issues.apache.org/jira/browse/DERBY-3254 DERBY-3327 SQL roles: Implement authorization stack https://issues.apache.org/jira/browse/DERBY-3327 DERBY-3137 SQL roles: add catalog support https://issues.apache.org/jira/browse/DERBY-3137 DERBY-3324 JDBC statement cache implementation https://issues.apache.org/jira/browse/DERBY-3324 DERBY-3088 convert to junit, or otherwise eliminate version in tests which require an update of the master in the release management process https://issues.apache.org/jira/browse/DERBY-3088 DERBY-3169 Add documentation for replication https://issues.apache.org/jira/browse/DERBY-3169 DERBY-3184 Replication: Connection attempts to a database in slave mode must fail https://issues.apache.org/jira/browse/DERBY-3184 DERBY-2871 XATransactionTest gets XaException: Error executing a XAResource.commit(), server returned XAER_PROTO. https://issues.apache.org/jira/browse/DERBY-2871 DERBY-3117 Adjust master build script to require the Java 5 compiler to build Derby https://issues.apache.org/jira/browse/DERBY-3117 DERBY-2953 Dump the information about rollbacks of the global transaction (introduced in DERBY-2220 and DERBY-2432) to derby.log https://issues.apache.org/jira/browse/DERBY-2953 DERBY-3083 Network server demands a file called derbynet.jar in classpath https://issues.apache.org/jira/browse/DERBY-3083 DERBY-3227 Remove final from all getConnection() methods in EmbeddedDataSource https://issues.apache.org/jira/browse/DERBY-3227
[jira] Updated: (DERBY-3050) Convert groupBy.sql tests to JUnit and include them in GroupByTest.java
[ https://issues.apache.org/jira/browse/DERBY-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton updated DERBY-3050: --- Derby Info: [Patch Available] Set patchAvailable flag to request more feedback. I haven't yet run the complete test suites with this patch, but GroupByTest by itself runs correctly in my environment. If people are generally comfortable with this patch, I'll move ahead with more complete testing. Convert groupBy.sql tests to JUnit and include them in GroupByTest.java --- Key: DERBY-3050 URL: https://issues.apache.org/jira/browse/DERBY-3050 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.4.0.0 Reporter: Bryan Pendleton Assignee: Bryan Pendleton Priority: Minor Attachments: convertToJunit.diff, convertToJUnit.diff, convertToJUnit.stat There are currently 3 sets of GROUP BY tests: - GroupByExpressionTest.java - GroupByTest.java - groupBy.sql The first two tests are JUnit tests; the groupBy.sql tests are old-style harness tests, although they are now run in the JUnit framework using the LangScripts technique. This sub-task proposes to convert the groupBy.sql tests to JUnit tests, and to include them directly into GroupByTest.java. The DERBY-2151 conversion tool can be used to assist in the conversion process. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3050) Convert groupBy.sql tests to JUnit and include them in GroupByTest.java
[ https://issues.apache.org/jira/browse/DERBY-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton updated DERBY-3050: --- Attachment: convertToJunit.diff Attached is a new version of 'convertToJunit.diff'. This version substantially revises GroupByTest.java to address Manish's suggestions regarding test case organization. I have broken the monolithic test case generated by the conversion tool into a dozen sub-tests, according to boundaries that seemed reasonable to me. I also: - consolidated all the table creation/population logic into setUp() and the drop logic into tearDown() - revised the existing test cases in GroupByTest to match - removed the line which was setting autocommit to false, and simply had all the tests run in autocommit mode. The .stat file is unchanged; this patch deletes 4 files and modifies 2. I'm still a beginner at this process of converting the old-style IJ script tests to JUnit, so there are probably more things I've missed. So, please have a look at this new patch and provide more feedback! Convert groupBy.sql tests to JUnit and include them in GroupByTest.java --- Key: DERBY-3050 URL: https://issues.apache.org/jira/browse/DERBY-3050 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.4.0.0 Reporter: Bryan Pendleton Assignee: Bryan Pendleton Priority: Minor Attachments: convertToJunit.diff, convertToJUnit.diff, convertToJUnit.stat There are currently 3 sets of GROUP BY tests: - GroupByExpressionTest.java - GroupByTest.java - groupBy.sql The first two tests are JUnit tests; the groupBy.sql tests are old-style harness tests, although they are now run in the JUnit framework using the LangScripts technique. This sub-task proposes to convert the groupBy.sql tests to JUnit tests, and to include them directly into GroupByTest.java. The DERBY-2151 conversion tool can be used to assist in the conversion process. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3050) Convert groupBy.sql tests to JUnit and include them in GroupByTest.java
[ https://issues.apache.org/jira/browse/DERBY-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560852#action_12560852 ] Daniel John Debrunner commented on DERBY-3050: -- 'm still a beginner at this process of converting the old-style IJ script tests to JUnit ... Just a reminder that setup and tearDown is executed once per fixture (each testXXX method) not once per class. From a quick look at the test fixtures it seems they do not modify the data, thus would it make more sense to perform the setup using the facilities of CleanDatabaseTestSetup? Ie. CleanDatabaseTestSetup.decorateSQL. Then no test specific code is needed for cleanup. Usuallly test classes do not need instance variables for JDBC objects (e.g Statements and ResultSets). They provide almost no benefit and have the downside that either code is needed to clean them up (assign the fields to null) or they continue to use memory after the test has finished. Such fields provide no benefit because the object in the field (e.g. a Statement) is not shared across fixtures, each fixture is represented by a unique instance of the class, thus with N fixutures N Statements will be created rather than the one that might be assumed by using a field. Since the Statement is local to the fixture it becomes cleaner to keep it locally scoped in the testXXX() fixture method, passing it into utility methods as required. The only benefit can be sharing a Statement object across a testXXX fixuture method and setup/teardown methods. Since Statement objects are not expensive to create then I think this is of dubious value, I think it's clearer for someone reading the test later to understand the code with a locally scoped object rather than an instance object. Convert groupBy.sql tests to JUnit and include them in GroupByTest.java --- Key: DERBY-3050 URL: https://issues.apache.org/jira/browse/DERBY-3050 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.4.0.0 Reporter: Bryan Pendleton Assignee: Bryan Pendleton Priority: Minor Attachments: convertToJunit.diff, convertToJUnit.diff, convertToJUnit.stat There are currently 3 sets of GROUP BY tests: - GroupByExpressionTest.java - GroupByTest.java - groupBy.sql The first two tests are JUnit tests; the groupBy.sql tests are old-style harness tests, although they are now run in the JUnit framework using the LangScripts technique. This sub-task proposes to convert the groupBy.sql tests to JUnit tests, and to include them directly into GroupByTest.java. The DERBY-2151 conversion tool can be used to assist in the conversion process. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3050) Convert groupBy.sql tests to JUnit and include them in GroupByTest.java
[ https://issues.apache.org/jira/browse/DERBY-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton updated DERBY-3050: --- Attachment: convertToJunit.diff Thanks Dan! Updating the test to use CleanDatabaseTestSetup has the added benefit that the test now runs in 9 seconds, where it was taking close to a minute before. Very nice. In addition to using CleanDatabaseTestSetup, I also made the Statement and ResultSet variables local to the test case. Convert groupBy.sql tests to JUnit and include them in GroupByTest.java --- Key: DERBY-3050 URL: https://issues.apache.org/jira/browse/DERBY-3050 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.4.0.0 Reporter: Bryan Pendleton Assignee: Bryan Pendleton Priority: Minor Attachments: convertToJunit.diff, convertToJunit.diff, convertToJUnit.diff, convertToJUnit.stat There are currently 3 sets of GROUP BY tests: - GroupByExpressionTest.java - GroupByTest.java - groupBy.sql The first two tests are JUnit tests; the groupBy.sql tests are old-style harness tests, although they are now run in the JUnit framework using the LangScripts technique. This sub-task proposes to convert the groupBy.sql tests to JUnit tests, and to include them directly into GroupByTest.java. The DERBY-2151 conversion tool can be used to assist in the conversion process. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560902#action_12560902 ] Craig Russell commented on DERBY-3301: -- Too late to keep working - EXIST should return only one row. There are many ways to evaluate the query, depending on the strategy. Yes, each of the EXISTS clauses should return either zero or one row, depending on whether the EXISTS condition is true for the specific row of the outermost FROM clause. For each row of the outer product of the outermost FROM clause (DEPARTMENTS, EMPLOYEES, PROJECTS), the middle WHERE EXISTS should return true when there is a match between the EMPLOYEES and PROJECTS in the join table. As an optimization, you could invert the scan and look at all of the rows of the join table. It's hard to tell from the analysis here whether Derby is inverting the scan. Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1 Reporter: Craig Russell Attachments: d3301-queryplan.log, derby-3301.sql Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) ); PERSONID |PROJID --- 3 |1 5 |3 4 |3 2 |1 1 |1 5 rows selected I'm expecting 7 rows to be returned here, one row for each row in the join table. Here's the schema: CREATE TABLE departments ( ID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, EMP_OF_THE_MONTH INTEGER, COMPANYID INTEGER, DISCRIMINATOR VARCHAR(255), CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies, CONSTRAINT DEPTS_PK PRIMARY KEY (ID) ); CREATE TABLE persons ( PERSONID INTEGER NOT NULL, FIRSTNAME VARCHAR(32) NOT NULL, LASTNAME VARCHAR(32) NOT NULL, MIDDLENAME VARCHAR(32), BIRTHDATE TIMESTAMP NOT NULL, ADDRID INTEGER, STREET VARCHAR(64), CITY VARCHAR(64), STATE CHAR(2), ZIPCODE CHAR(5), COUNTRY VARCHAR(64), HIREDATE TIMESTAMP, WEEKLYHOURS REAL, DEPARTMENT INTEGER, FUNDINGDEPT INTEGER, MANAGER INTEGER, MENTOR INTEGER, HRADVISOR INTEGER, SALARY REAL, WAGE REAL, DISCRIMINATOR varchar(255) NOT NULL, CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments, CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES departments, CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons, CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons, CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons, CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID) ); CREATE TABLE projects ( PROJID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, BUDGET DECIMAL(11,2) NOT NULL, DISCRIMINATOR VARCHAR(255), CONSTRAINT PROJS_PK PRIMARY KEY (PROJID) ); CREATE TABLE project_member ( PROJID INTEGER REFERENCES projects NOT NULL, MEMBER INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY |STA|ZIPC|COUNTRY |HIREDATE
[jira] Updated: (DERBY-3254) Implement the replication failover functionality
[ https://issues.apache.org/jira/browse/DERBY-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3254: --- Attachment: failover_impl_v5.stat failover_impl_v5.diff I have addressed all the comments pointed out and have also fixed the ErrorCodeTest failure. I am running tests on this patch and shall post the results of the run by today afternoon. I request for this patch to be considered for reviews and comments. Implement the replication failover functionality Key: DERBY-3254 URL: https://issues.apache.org/jira/browse/DERBY-3254 Project: Derby Issue Type: Sub-task Components: Replication Reporter: V.Narayanan Assignee: V.Narayanan Attachments: failover_impl_notforcommit.diff, failover_impl_notforcommit.stat, failover_impl_v1.diff, failover_impl_v1.stat, failover_impl_v2.diff, failover_impl_v2.stat, failover_impl_v3.diff, failover_impl_v3.stat, failover_impl_v4.diff, failover_impl_v4.stat, failover_impl_v5.diff, failover_impl_v5.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Please add my JIRA id to derby developers list
Dibyendu Majumdar wrote: My JIRA id is dibyendumajumdar. Thanks and Regards Dibyendu added, and welcome, -jean
[jira] Updated: (DERBY-3205) Replication: Add connection url command options for starting, stopping slave and for failover
[ https://issues.apache.org/jira/browse/DERBY-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3205: --- Attachment: failover_impl_3205_v1.stat failover_impl_3205_v1.diff I have addressed the issues found in the earlier failover url. Pls note that this patch is dependent on the failover implementation that being done as part of Derby-3254 and will not compile without the startFailover method introduced in 3254. Replication: Add connection url command options for starting, stopping slave and for failover - Key: DERBY-3205 URL: https://issues.apache.org/jira/browse/DERBY-3205 Project: Derby Issue Type: Sub-task Components: JDBC Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: V.Narayanan Attachments: derby-3205_startslave_dontcommit.diff, derby-3205_startslave_dontcommit.stat, failover_impl_3205_NotForCommit_v1.diff, failover_impl_3205_NotForCommit_v1.stat, failover_impl_3205_v1.diff, failover_impl_3205_v1.stat, startSlave_1a.diff, startSlave_1a.stat, startSlave_1b.diff, startSlave_1b.stat, startSlave_1c.diff, startSlave_1d.diff, StopSlave_impl_3205_NotForCommit_v1.diff, StopSlave_impl_3205_NotForCommit_v1.stat Add commands to start and stop the replication slave using properties or connection url. Example: 'jdbc:derby:hostdbname;startSlave=true'; 'jdbc:derby:hostdbname;stopSlave=true'; 'jdbc:derby:hostdbname;failover=true; Connection url options that must be recognized: startSlave=true stopSlave=true failover=true slaveHost=host (optional, defaults to localhost) (only for startSlave) slavePort=port (optional, defaults to 8001) (only for startSlave) See functional specification on Derby-2872 for further details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3235) Implement the replication stop functionality
[ https://issues.apache.org/jira/browse/DERBY-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3235: --- Attachment: StopImplementation_v3.stat StopImplementation_v3.diff I encountered a similar problem while working on the failover issue, I resolved the issue using AsynchronousLogShipper#stopLogShippment. I have done the same for the issue pointed out by using AsynchronousLogShipper#stopLogShippment in MasterController#stopMaster. I am yet to run tests on this patch, will run the tests and shall revert back with the results. Implement the replication stop functionality Key: DERBY-3235 URL: https://issues.apache.org/jira/browse/DERBY-3235 Project: Derby Issue Type: Sub-task Components: Replication Affects Versions: 10.4.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Attachments: StopImplementation_v1.diff, StopImplementation_v1.stat, StopImplementation_v1_NotForCommit.diff, StopImplementation_v1_NotForCommit.stat, StopImplementation_v2.diff, StopImplementation_v2.stat, StopImplementation_v3.diff, StopImplementation_v3.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Getting the LangaugeConnectionContext
Really thanks for the reply... Is it possible to get the LCC at some later point of execution : in the JDBCDisplayUtil? I have got the Connection object in the function that i need. I want to if its possible to get the activation object related to the current connection. By the way, why is that getCurrentLCC() throws an error when used in JDBCDisplayUtil but not when it is used in classes such as ConsistencyChecker, etc..? On Jan 20, 2008 6:07 PM, Thomas Nielsen [EMAIL PROTECTED] wrote: Hi Jazarine, I'm assuming you need to get the LCC once you are in the execute phase, and in a class implementing ResultSet. All the different ResultSet implementations in org.apache.derby.impl.sql.execute get an activation supplied to their constructor either directly, or through its source/child ResultSet. It should hence be available either: - as a member of the given ResultSet class - though the ResultSets source/child ResultSet - through getLanguageConnectionContext() - or through getActivation().getLanguageConnectionContext() depending on the ResultSet class implementation you are in. It could be beneficial to have a look around ProjectRestrictNodeResultSet, the top-most ResultSet for a SELECT qry, and see how it's fetched/used? Activations are created/built with an ActivationClassBuilder and is populated during the bytecode generation phase. You can see one example of how the ActivationClassBuilder is used in ProjectRestrictNode.generateMinion() in org.apache.derby.impl.sql.compile. ProjectRestrictNode is the node generating the ProjectRestrictNodeResultSet (and a few others for the sake of correctness). Generally we push objects to the stack, then call to ActivationClassBuilder to push generation of the correct type of ResultSet on the stack. This is where the actual Activation object is created, and as previously stated it's often pushed as a parameter to the ResultSet constructor. Once code generation is completed, we start executing the generated bytecode. Someone with a little more knowledge of the details may want to explain this further, or correct me, if necessary? :) Hope this helps you figure it out :) Thomas Jazarine Jamal wrote: I need to get the langaugeconnectioncontext. I presume it can be done through this: LangaugeConnectionContext=activation.getLangaugeConnectionContext() But How do I create an Activation object? Are there any implemented classes for Activation interface..?? I am doing this since it forms a part of the code to get the type of an object. Please get me some help as soon as possible..
Re: Finding object type
Is there a function in the derby source code to find the type of an object.. i.e. if the XXX is a table , it should return 'TABLE' .. if YYY is a view, it should return 'VIEW'.. or anything like that?? please tell where to look for it.. please help asap... Hi Jazarine, Would it be possible to use JDBC in your case? If so, you could e.g. have a look at DatabaseMetaData.getTables (check out the Java API). If that is not an option, you may write a query like the one below to get all non-system tables and views. select tablename, tabletype from sys.systables where tabletype not like 'S'; A tabletype of T is a normal table, while V means view. These methods should work if you want to find the table type from an application using Derby. If you want to find the tabletype *inside Derby* (because you modify the source code), I would start looking at org.apache.derby.client.am.DatabaseMetaData#getTables and find out what happens there. Hope this helps -- Jørgen Løland
