Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 13 Mar 2014 16:11:55 +0000 (UTC)
From: "Peter (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12701009.1394641510577.60507.1394727115762@arcas>
In-Reply-To: <JIRA.12701009.1394641510577@arcas>
References: <JIRA.12701009.1394641510577@arcas>
Subject: [jira] [Commented] (CASSANDRA-6846) Provide standard interface for
 deep application server integration
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Peter commented on CASSANDRA-6846:
----------------------------------

I want Cassandra to be a performant database first. My desire is for easier and more friendly query capabilities. I want to be able to queries like 
select col1, col2, col3 from MyColFamily where col1='blah1' or col2='blah2'
select * from MyColFamily2 where col3 IN ('blah4,',blah5','blah6') group by col2
select * from MyColFamily3 where col5 LIKE '%blah' and col8 LIKE 'blah2%'

I don't know which approach is the right way to go, but I do feel discussion can help flush out pros/cons. At first I thought about doing all of this on the client side by writing a SQL parser, query planner and query optimizer, but it would need to be done for every single language. When I ported Hector to C#, I thought about implementing a full LINQ implementation so that uses can do more complex queries, but then I have two completely different code bases for doing similar things. Having "some" enhancement on the server can reduce the amount of work for driver implementators. Another approach would be to use Solr libraries to make a custom index, which I'm sure others have thought about doing. Then there's approaches like spark/shark, presto, etc.

> Provide standard interface for deep application server integration
> ------------------------------------------------------------------
>
>                 Key: CASSANDRA-6846
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6846
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Tupshin Harper
>            Assignee: Tupshin Harper
>            Priority: Minor
>              Labels: ponies
>
> Instead of creating a pluggable interface for Thrift, I'd like to create a pluggable interface for arbitrary app-server deep integration.
> Inspired by both the existence of intravert-ug, as well as there being a long history of various parties embedding tomcat or jetty servlet engines inside Cassandra, I'd like to propose the creation an internal somewhat stable (versioned?) interface that could allow any app server to achieve deep integration with Cassandra, and as a result, these servers could 
> 1) host their own apis (REST, for example
> 2) extend core functionality by having limited (see triggers and wide row scanners) access to the internals of cassandra
> The hand wavey part comes because while I have been mulling this about for a while, I have not spent any significant time into looking at the actual surface area of intravert-ug's integration. But, using it as a model, and also keeping in minds the general needs of your more traditional servlet/j2ee containers, I believe we could come up with a reasonable interface to allow any jvm app server to be integrated and maintained in or out of the Cassandra tree.
> This would satisfy the needs that many of us (Both Ed and I, for example) to have a much greater degree of control over server side execution, and to be able to start building much more interestingly (and simply) tiered applications.


--
This message was sent by Atlassian JIRA
(v6.2#6252)