Buildable project with the CassandraRepository interface

[boneill42]

Buildable project with the CassandraRepository interface

[odrotbohm]

What's the intent of this pull request? It doesn't seem to contain a real repository abstraction implementation, so I am a bit puzzled actually :)

[boneill42]

I wanted to use it to drive a conversation around the status of the
project.
I sent an email to Erez, but didn't hear back.

Is the project still alive? Does any code exist?

All I see in the repository is a README.

I'd like to build out this layer if no one is working on it.

-brian

Brian O'Neill
Lead Architect, Software Development
Health Market Science | 2700 Horizon Drive | King of Prussia, PA 19406
p: 215.588.6024
www.healthmarketscience.com

On 6/28/12 12:33 PM, "Oliver Gierke"
<reply+i-5322779-560c67b55d207402adc3efe446ba5c75cb89b3f9-897229@reply.gith
ub.com> wrote:

What's the intent of this pull request? It doesn't seem to contain a real
repository abstraction implementation, so I am a bit puzzled actually :)

---

Reply to this email directly or view it on GitHub:
#1 (comment)
6634585

[odrotbohm]

That's cool to hear! No there's currently no SpringSource developers working on the Cassandra module and we also currently don't have plans to change this in the near future. However there seems to be a community starting to rise to build implementations of the Spring Data repository abstraction (e.g. Solr, RDF). So we definitely would be happy to see community involvement here as well. I'll drop you an email with my Skype account so we can have a 1:1 discussion in case you have questions going forward.

[prowave]

I am interested in helping out on this project.

[boneill42]

Great to hear. We'll have to dust it off a bit, but if you want to fork from boneill42/spring-data-cassandra that may give you a place to start.

[prowave]

Brian,

Is there a list of requirements to work from? Are requirements tracked in Jira or here? Can you give me an overall status of where you left off? Was the intention to mimic similar functionality like spring-data-mongo (or other NoSQL Data Sources)?

Finally, when we get it ready, what is the process to get the code back into this SpringSource repository and available for general release?

I can see where you requested to merge your commits into this branch. Any reason why that hasn't happened yet?

Thanks,
Dave

[odrotbohm]

Dave, the reason we haven't proceeded here were essentially twofold:

1. We didn't feel that a JPA based implementation makes a whole lot of sense as you essentially create a profile of it only and have to offer custom means for Cassandra specific features anyway. Instead of using Kundera we we rather thinking about a dedicated Cassandra integration based on Netflix' Astayanax.
2. While an initial code contribution is fine, we never got to the point of discussing ongoing involvement into the project. We didn't really feel the PR was ready yet and there was no clear commitment of who is going to take the module forward etc.

I think it's best to start in a custom repository and have a look at the feature matrix exposed here. As soon as one can check roughly 80% of the boxes we can think of a migration. Does that make sense to you?

[prowave]

Oliver,

Thanks for the response. I agree on not using JPA. I think either a Astayanax or Hector client integration makes the most sense. Do you have an opinion either way?

I will use the spring-data-mongodb project as a reference since it appears to be well implemented.

Can you give me the ability to add Jiras to the DATACOL project so I can manage sprints and track progress there?

I have a couple other guys I am going to try and recruit to help me out once I get everything ready to go.

Thanks,
Dave

[boneill42]

I actually paused work because I intended to use the CQL java driver. Since the thrift support in C* is going away (eventually), I thought it might be better to bet on CQL.

The CQL java driver just went 1.0. So, we may want to start there, unless we can come up with a compelling reason not to use it.

[markpollack]

Seems like Astayanax also supports CQL

from the readme

If using Cassandra 1.2 and CQL then you will need to tell Astyanax about it. For now, Astyanax has defaults for Cassandra 1.1

AstyanaxContext context = new AstyanaxContext.Builder()
.withAstyanaxConfiguration(new AstyanaxConfigurationImpl()
.setCqlVersion("3.0.0")
.setTargetCassandraVersion("1.2")
)
...

Wouldn't we end up redoing a lot of what is in Astyanax (e.g. pagination) if going with just the CQL driver?

[boneill42]

Astyanax supports CQL, but AFAIK it still sends that over the thrift interface. The problem with that is that it doesn't support some of the newer features very well. (e.g. collections)
http://brianoneill.blogspot.com/2013/01/native-support-for-collections-in.html
https://issues.apache.org/jira/browse/CASSANDRA-3647

I'm cool going with Astyanax. (We use that internally here)
But it may not be as "future proof" as a CQL-based implementation. The native protocol seems to have the momentum behind it right now. New C* features may not be supported very well via thrift.

But I agree, we may need to re-write some of the functionality in Astyanax.
(although chances are people are working on it already in the CQL java driver)

I'm cool either way, just want to make the selection with eyes wide open.

[boneill42]

Just an FYI -- same topic came up on the Hector thread yesterday:
https://groups.google.com/forum/?fromgroups#!topic/hector-users/2yqpbqpV9FY

[markpollack]

From what you are saying I would prefer not to rely on the thrift interface if that is going to be deprecated. Why the shift away from thrift?

[prowave]

Thrift is a dependency of the DataStax CQL Java Driver. So a change isnt really a move away from thrift, right?

I am continuing on with the development of the module using Astyanax. Changing out the underlying driver is not that much work in the grand scheme of things. Also, supporting both Thrift and CQL for a period of time might be the best option and increase adoption of the spring-data-cassandra module.

http://www.datastax.com/doc-source/developer/java-driver/#reference/settingUpJavaProgEnv_r.html

Fourth one down.

Unless I am missing something, we have to get "V1.0" out there with the expectation that it will evolve over time. :)

[boneill42]

Like I said, I'm not that passionate either way. If we can get things out faster using Astyanax, let's do that.

Just as background information... the CQL java driver includes the thrift dependency, but it doesn't use the thrift protocol. In Cassandra 1.2, the database actually listens on two separate ports: the legacy thrift port (9160), and the new "native" protocol (port 9042). The CQL java-driver connects over the native protocol, while all the other java apis still use the legacy port/protocol.

Here was the rational for CQL:
http://www.datastax.com/docs/1.2/cql_cli/using_cql
"CQL 3 is the default and primary interface into the Cassandra DBMS. CQL 3 provides a new API to Cassandra that is simpler than the Thrift API for new applications. The Thrift API, the Cassandra Command Line Interface (CLI), and legacy versions of CQL expose the internal storage structure of Cassandra. CQL 3 adds an abstraction layer that hides implementation details and provides native syntaxes for CQL 3 collections and other common encodings"

Here is what you see in the Cassandra config (in cassandra.yaml):
# Whether to start the native transport server.
# Currently, only the thrift server is started by default because the native
# transport is considered beta.
# Please note that the address on which the native transport is bound is the
# same as the rpc_address. The port however is different and specified below.
start_native_transport: true
# port for the CQL native transport to listen for clients on
native_transport_port: 9042

[markpollack]

Thanks for the info. Is it worth providing a driver abstraction as we did in redis? It is a fair bit of work and don't want to go down a rabbit-hole unnecessarily.

I'm surprised the decision might effect how well spring-data-cassandra would be adopted, is that because many people are hesitant to change to use a new protocol or only want to run the server using the native transport as that is what is in production already....?

[prowave]

The adoption comment was not well communicated on my part. I was trying to say that Spring Data is not an option today if you need to talk to Cassandra. We need to get the module out there in order for it to be adopted. :)

I am willing to put in the time to make that happen. I am not the expert on Spring Data like you guys are, but I am quite familiar with Cassandra. I am open to going with your recommendation. Thanks for having the discussion.

[markpollack]

Astayanax looks overall like a nice starting point - I am a bit concerned about one thing - the mapping that they provide uses JPA annotations.

https://github.com/Netflix/astyanax/wiki/Entity-persister

That is something we have consciously decided against. Oliver, what are your thoughts here? We can also write our own entity-persister with our own less JPA centric annotations that uses the rest of Astayanax.

And thanks for taking up interest in this and spending your time on it!

[boneill42]

I don't think the choice of cassandra java API will matter in people's decision to use spring-data-cassandra.

RE: JPA in Astyanax
We need not use it. Astyanax provides row/column level functions for everything as well.
(i.e. you don't need to use annotated objects at all)

BTW -- great to see this kicking off.

[prowave]

I will open a new Issue to discuss how to map Cassandra Rows to Beans. Thanks for the helpful info.

From: boneill42 [mailto:notifications@github.com]
Sent: Friday, May 24, 2013 6:57 PM
To: SpringSource/spring-data-cassandra
Cc: David T. Webb
Subject: Re: [spring-data-cassandra] Buildable project with the CassandraRepository interface (#1)

I don't think the choice of cassandra java API will matter in people's decision to use spring-data-cassandra.

RE: JPA in Astyanax
We need not use it. Astyanax provides row/column level functions for everything as well.

(i.e. you don't need to use annotated objects at all)

BTW -- great to see this kicking off.

—
Reply to this email directly or view it on GitHub #1 (comment) . https://github.com/notifications/beacon/W92xDhzNTBnN1R9G7eR001cB9VUJhgfuN6xQPSUayIflHLIuvuSgnBrJ6XsgKsAp.gif

[markpollack]

Ok, so let's use Astyanax as the starting point but not use their JPA based model for mapping. Our mapper might be very similar, using different annotations, or have other features.

[prowave]

Are there any current spring-data-? projects that use an entity-persiter / mapper similar to what you guys want to replace the Astyanax one with? I am looking for a good starting point that is similar to other spring data modules. Thanks.

[prowave]

Mark,

I have found the Astyanax entity mapper and will modify it to use non JPA annotations, then incorporate it into this project. That should be the most efficient way to get this going. It doesn’t look like a very large effort either.

-Dave

[prowave]

This request is no longer valid with the new source tree.