[
https://issues.apache.org/jira/browse/CASSANDRA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2936:
--------------------------------------
Attachment: 2936-cleanup.txt
Ugh, I wish we hadn't touched the AbstractType->AbstractTerm refactor. It
doesn't improve things from the dependency standpoint (the latter still depends
on the former) and we should be avoiding 11th hour refactors like this where
possible (e.g. this screwed CASSANDRA-2734 all to hell).
Having come this far, though, I propose the attached patch:
- removes ATerm.isCommutative, which is unused and likely to remain so
(commutativity is an internal property of counters)
- removes AType.toString, which is unused outside of client code, which leaves
us with a single-direction dependency instead of bidirectional
I further propose renaming AbstractTerm to AbstractJdbcType, and LongTerm,
IntegerTerm, etc., to JdbcLong, JdbcInteger, etc., both on semantic grounds (a
"term" implies a concrete use in a parse tree or statement, not a generic type)
and pedantic (it's unfortunate that the CamelCase abbreviations of *Type and
*Term are identical).
> improve dependency situation between JDBC driver and Cassandra
> --------------------------------------------------------------
>
> Key: CASSANDRA-2936
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2936
> Project: Cassandra
> Issue Type: Improvement
> Components: API, Core
> Affects Versions: 0.8.1
> Reporter: Eric Evans
> Assignee: Eric Evans
> Priority: Minor
> Labels: cql
> Fix For: 1.0
>
> Attachments: 2936-cleanup.txt,
> v1-0001-CASSANDRA-2936-rename-cookie-jar-clientutil.txt,
> v3-0001-CASSANDRA-2936-create-package-for-CQL-term-marshaling.txt,
> v3-0002-convert-drivers-and-tests-to-o.a.c.cql.term.txt,
> v3-0003-remove-extraneous-methods-from-o.a.c.db.marshal-classe.txt,
> v3-0004-make-better-reuse-of-new-classes.txt, v3-0005-create-jar-file.txt
>
>
> The JDBC jar currently depends on the {{apache-cassandra-$version}} jar,
> despite the fact that it only (directly) uses a handful of Cassandra's
> classes. In a perfect world, we'd break those classes out into their own jar
> which both the JDBC driver and Cassandra (ala
> {{apache-cassandra-$version.jar}}) could depend on. However, the classes
> used directly don't fall out to anything that makes much sense
> organizationally (short of creating a
> {{apache-cassandra-misc-$version.jar}}), and the situation only gets worse
> when you take into account all of the transitive dependencies.
> See CASSANDRA-2761 for more background, in particular
> ([this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13048734&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13048734]
> and
> [this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13050884&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13050884])
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
