Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 13 Mar 2014 19:59:46 +0000 (UTC)
From: "Peter (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12701009.1394641510577.62779.1394740786747@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=13933963#comment-13933963 ] 

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


Having implemented an expert system shell in the past and a LISP interpreter, UDF's are good for a class of problems. Where performance really matters, being able to do it at a lower level definitely gives more options for optimizing performance. Writing query planners isn't that hard, writing a really good one is very very hard. Being able to integrate at IDiskAtomFilter level "should" give users the ability to optimize for their specific needs.
If we look at RDBMS history, most of them had low level hooks for customers that needed them. 99% of the users never had to use it, but those that did were glad it was there. Of course it's also ripe for abuse on benchmarks when vendors took advantage to game TPC-C.
A really dumb question, how likely is it that IDiskAtomFilter will change? I took a quick look on github and it looks like it has been fairly stable since 2012. I would imagine if the storage format changes, IDiskAtomFilter would need to be updated. I ask for a couple of reasons. I'm interesting in implementing Bitmap indexes for Cassandra. I haven't dug deep enough to know what it would take to add bitmap indexes. I've been reading over the index code the last 2 weeks in my spare time.

> 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)