[ http://issues.apache.org/jira/browse/DERBY-1291?page=comments#action_12379106 ]
Rick Hillegas commented on DERBY-1291: -------------------------------------- Thanks to Satheesh for pointing out the previous email discussion of a similar refactoring for the Network client: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200505.mbox/browser. Thanks to Dan for bringing up the serious issue of the change in our public contract. This change has been made to the Network client already: DERBY-1246, subversion revision 396881. If we decide to reject this refactoring for the Embedded implementation, then the same arguments probably apply to the Network implementation and we should back out the DERBY-1246 patch. I will try to recap the concerns from the earlier email thread: Arguments in favor of the refactoring: + It makes our implementations mirror the inheritance graph of the javax.sql interfaces. (This is also the motivation for the current proposed change and for DERBY-1246: JDBC4 makes the old implementation more awkward in that now Derby's XADataSources and ConnectionPoolDataSources must implement the Wrapper interface as well.) The departure from the javax.sql inheritance graph can create confusion for application servers, the likely users of the XADataSource and ConnectionPoolDataSource interfaces + The refactoring eliminates the possibility of someone erroneously calling getConnection() on one of our XADataSources or ConnectionPoolDataSources. I do not understand the danger here. Can someone clarify? Arguments against the refactoring: - The Network and Embedded implementations should mirror one another so that applications can easily port from one to the other. Satheesh noted that the Network hierarchy was modelled on the Embedded hierarchy and wondered why the Embedded hierarchy was coded the way it was. In the email thread, Dan voted +0 on the proposed refactoring. Kathey initially voted -1, but later retracted her veto, provided that the Embedded and Network implementations mirrored one another. For reasons which I don't see in that thread, the actual refactoring was not done at that time. As noted above, the Network work happened in DERBY-1246. It seems to me that if we adopt this patch, or some refinement of it, then our Network and Embedded implementations will again agree. The same is true if we reject this refactoring and back out DERBY-1246. I think there is broad consensus that the two implementations should mirror one another. That leaves Dan's serious objection that we are changing the contract of public classes. If such a change to our public contract is simply not allowed in a minor release like 10.2, then we should reject this approach and back out DERBY-1246. However, if such a change is allowed, then we should consider our exposure here. Here are my thoughts: o There is minimal exposure for app servers and other applications which are coded to be portable against the javax.sql interfaces. o However, there is substantial exposure for applications which are not coded to be portable but which are coded against the Derby api rather than the javax.sql api. As is clear from the email thread, the relationship among DataSource, XADataSource, and ConnectionPoolDataSource is confusing. If we decide to accept this refactoring, then we should document this in the release notes. > Modify DataSource classes of Embedded Driver to seperate DataSource , > XADataSource and ConnectionPooledDataSource > ------------------------------------------------------------------------------------------------------------------ > > Key: DERBY-1291 > URL: http://issues.apache.org/jira/browse/DERBY-1291 > Project: Derby > Type: Improvement > Components: JDBC > Versions: 10.2.0.0 > Reporter: Anurag Shekhar > Assignee: Anurag Shekhar > Attachments: derby-1291.diff > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
