cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Evans (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (CASSANDRA-2936) improve dependency situation between JDBC driver and Cassandra
Date Tue, 06 Sep 2011 12:00:15 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097918#comment-13097918
] 

Eric Evans edited comment on CASSANDRA-2936 at 9/6/11 11:59 AM:
----------------------------------------------------------------

{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 or 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

      was (Author: urandom):
    {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

        

Mime
View raw message