[
https://issues.apache.org/jira/browse/CASSANDRA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097918#comment-13097918
]
Eric Evans commented on CASSANDRA-2936:
---------------------------------------
{quote}
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)
{quote}
I don't understand. AbstractType depending on AbstractTerm was intentional,
avoiding it would have required duplication and refactoring that would have
been more disruptive (as-is, this pretty much just moved things around some).
AbstractTerm though shouldn't be depending on AbstractType (and I tested the
driver against the new jar), what I am I missing?
{quote}
and we should be avoiding 11th hour refactors like this where possible (e.g.
this screwed CASSANDRA-2734 all to hell).
{quote}
Not sure what to say here. It happens (especially when working from patchsets
attached to tickets and not branches). I'd have coordinated if I'd have known
there would be a problem, I apologize, and would be more than happy to help
sort that out if you'd like.
{quote}
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).
{quote}
+1
> 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
