You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by jcllings <jc...@gmail.com> on 2014/07/21 01:17:40 UTC
Which way to Cassandraville?
So I'm a Java application developer and I'm trying to find entry points
for learning to work with Cassandra.
I just finished reading "Cassandra: The Definitive Guide" which seems
pretty out of date and while very informative as to the technology that
Cassandra uses, was not very helpful from the perspective of an
application developer.
Having said that, what Java clients should I be looking at? Are there
any reasonably mature PoJo mapping techs for Cassandra analogous to
Hibernate? I can't say that I'm looking forward to yet another *QL
variant but I guess CQL is going to be a necessity. What, if any, GUI
tools are available for working with Cassandra, for data modelling?
Jim C.
Re: Which way to Cassandraville?
Posted by DuyHai Doan <do...@gmail.com>.
> Having said that, what Java clients should I be looking at? Are there
> any reasonably mature PoJo mapping techs for Cassandra analogous to
> Hibernate?
The Java Driver offers a basic object mapper in the mapper module. If you
look for something more evolved, have a look at
http://doanduyhai.github.io/Achilles/
Re: Which way to Cassandraville?
Posted by Robert Coli <rc...@eventbrite.com>.
On Tue, Jul 22, 2014 at 1:10 PM, Russell Bradberry <rb...@gmail.com>
wrote:
> Having an ORM says nothing about the maturity of a database, it says more
> about the community and their willingness to create one. The database
> itself has nothing to do with the creation of the ORM.
>
Except, as in this case, when one has baked what looks an awful lot like an
ORM into the Database... ;D
=Rob
Re: Which way to Cassandraville?
Posted by Russell Bradberry <rb...@gmail.com>.
Having an ORM says nothing about the maturity of a database, it says more about the community and their willingness to create one. The database itself has nothing to do with the creation of the ORM. Atop everything else, as was stated, knowing how to model your queries is the most important thing, more than knowing how to use the driver. Cassandra has a very specific way that it stores data, if you attempt to store data the way you do in any other RDBMS there is a good chance you will have a very hard time.
Also, this: http://my.safaribooksonline.com/book/databases/9780133440195
We wrote it for 1.2 but most all of the information still applies.
The performance gains you get from Cassandra come at a cost, that cost being that you need to know what you are doing.
On July 22, 2014 at 4:01:21 PM, jcllings (jcllings@gmail.com) wrote:
OK to clarify, I don't mean as an Administrator but an application developer. If you use an ORM how important is CQL3? The object being to eliminate any *QL from Java code.
Perhaps this technology isn't as mature as I thought.
Jim C.
On 07/22/2014 12:42 PM, DuyHai Doan wrote:
"What kinds of things would it be good to know for an interview?"
The underlying storage engine and how CQL3 maps to it. It's more than important, it's crucial. Knowing what you do and what you can't with CQL3 is not sufficient.
On Tue, Jul 22, 2014 at 9:20 PM, jcllings <jc...@gmail.com> wrote:
So It seems that:
1. There are indeed a few (3-4) mapping schemes.
2. CQL isn't very hard and represents a subset of (ANSI?) SQ92.
Both of these are validated based on further research and list guidance.
It appears that learning Cassandra from an application developers
perspective essentially means learning what you can't do at all and
learning what you can't do directly that you could do with an RDMBS.
This and keys and maybe a thing or two about replication strategies and
you should be good to go. Does this seem accurate?
What kinds of things would it be good to know for an interview?
Jim C.
Re: Which way to Cassandraville?
Posted by Robert Stupp <sn...@snazy.de>.
Yep - too easy. It does not matter what you use (CQL3, Pojo Mapper ;) or whatever). And I guess it's easier for a "pure Java coder knowing nothing about C*" to start with a mapper. But in the end you should know what's going on - since you will be in the position to fix bugs and performance issues. And I think there's no opposition when I say that it's better to prevent bugs ;)
The easiest way to learn things is just to start using it - play with it - make tests - dig around - build a prototype - benchmarks - performance tests - again and again. But throw away your prototype - start from scratch - with the lessons learned in mind :)
Am 22.07.2014 um 22:37 schrieb DuyHai Doan <do...@gmail.com>:
> "I surmise if you are using a mapper, it should be more a matter of knowing how the annotations map to the back-end rather than the CQL"
>
> It would be too easy. You should also know how the CQL3 maps to underlying data storage.
>
>
>
>
> On Tue, Jul 22, 2014 at 10:33 PM, jcllings <jc...@gmail.com> wrote:
>
> On 07/22/2014 01:11 PM, Robert Stupp wrote:
>> Let me respond with another question: How important is SQL for a JPA developer?
>> ...
>>
>> IMO mappers help and make life easier. Period.
>
>> Means: you should always know what the "thing" does to read/write your data. Practically not down to the details - but the concepts and pitfalls should be known.
>> If you don't you will get into trouble - sooner or later.
>>
>> Robert
>>
>> PS: I avoid the abbreviation ORM - it includes the term "relational" ;)
>>
>
> Agreed. That is why in previous posts I've been calling it "PoJo Mapping". When someone suggests I try on yet another hat, though, I get a little excited. ;-)
>
> In this case I've been wearing the ORM / RDBMS hat for long enough that I actually don't think about it much. So your point is made. I've already been wearing the hat in question. I surmise if you are using a mapper, it should be more a matter of knowing how the annotations map to the back-end rather than the CQL. This may make the transition easier, because as you say, it eliminates the cruft.
>
>
> Jim C.
>
Re: Which way to Cassandraville?
Posted by jcllings <jc...@gmail.com>.
On 07/22/2014 01:37 PM, DuyHai Doan wrote:
> "I surmise if you are using a mapper, it should be more a matter of
> knowing how the annotations map to the back-end rather than the CQL"
>
> It would be too easy. You should also know how the CQL3 maps to
> underlying data storage.
It would be if I intended to stop there. I was just picking a familiar
starting point. The best employee at any interview, of course, is both
omniscient and omnipotent.
Ah...but then we would be merely leasing in in HIS universe. ;-)
Jim C.
Re: Which way to Cassandraville?
Posted by DuyHai Doan <do...@gmail.com>.
"I surmise if you are using a mapper, it should be more a matter of knowing
how the annotations map to the back-end rather than the CQL"
It would be too easy. You should also know how the CQL3 maps to underlying
data storage.
On Tue, Jul 22, 2014 at 10:33 PM, jcllings <jc...@gmail.com> wrote:
>
> On 07/22/2014 01:11 PM, Robert Stupp wrote:
>
> Let me respond with another question: How important is SQL for a JPA
> developer?
> ...
>
> IMO mappers help and make life easier. Period.
>
>
> Means: you should always know what the "thing" does to read/write your
> data. Practically not down to the details - but the concepts and pitfalls
> should be known.
> If you don't you will get into trouble - sooner or later.
>
> Robert
>
> PS: I avoid the abbreviation ORM - it includes the term "relational" ;)
>
>
> Agreed. That is why in previous posts I've been calling it "PoJo
> Mapping". When someone suggests I try on yet another hat, though, I get a
> little excited. ;-)
>
> In this case I've been wearing the ORM / RDBMS hat for long enough that I
> actually don't think about it much. So your point is made. I've already
> been wearing the hat in question. I surmise if you are using a mapper, it
> should be more a matter of knowing how the annotations map to the back-end
> rather than the CQL. This may make the transition easier, because as you
> say, it eliminates the cruft.
>
>
> Jim C.
>
Re: Which way to Cassandraville?
Posted by jcllings <jc...@gmail.com>.
On 07/22/2014 01:11 PM, Robert Stupp wrote:
> Let me respond with another question: How important is SQL for a JPA
> developer?
> ...
> IMO mappers help and make life easier. Period.
> Means: you should always know what the "thing" does to read/write your
> data. Practically not down to the details - but the concepts and
> pitfalls should be known.
> If you don't you will get into trouble - sooner or later.
>
> Robert
>
> PS: I avoid the abbreviation ORM - it includes the term "relational" ;)
>
Agreed. That is why in previous posts I've been calling it "PoJo
Mapping". When someone suggests I try on yet another hat, though, I get
a little excited. ;-)
In this case I've been wearing the ORM / RDBMS hat for long enough that
I actually don't think about it much. So your point is made. I've
already been wearing the hat in question. I surmise if you are using a
mapper, it should be more a matter of knowing how the annotations map to
the back-end rather than the CQL. This may make the transition easier,
because as you say, it eliminates the cruft.
Jim C.
Re: Which way to Cassandraville?
Posted by Robert Stupp <sn...@snazy.de>.
Let me respond with another question: How important is SQL for a JPA developer?
Mappers eliminate the boring and error-prone stuff like "execute SELECT", "read fields", "call setters" etc. They can automatically perform conversions, apply optimizations, etc etc etc.
Mappers do not remove the need of a developer to think about that what (s)he's coding.
IMO mappers help and make life easier. Period.
Means: you should always know what the "thing" does to read/write your data. Practically not down to the details - but the concepts and pitfalls should be known.
If you don't you will get into trouble - sooner or later.
Robert
PS: I avoid the abbreviation ORM - it includes the term "relational" ;)
Am 22.07.2014 um 22:00 schrieb jcllings <jc...@gmail.com>:
> OK to clarify, I don't mean as an Administrator but an application developer. If you use an ORM how important is CQL3? The object being to eliminate any *QL from Java code.
> Perhaps this technology isn't as mature as I thought.
>
> Jim C.
>
> On 07/22/2014 12:42 PM, DuyHai Doan wrote:
>> "What kinds of things would it be good to know for an interview?"
>>
>> The underlying storage engine and how CQL3 maps to it. It's more than important, it's crucial. Knowing what you do and what you can't with CQL3 is not sufficient.
>>
>>
>>
>>
>> On Tue, Jul 22, 2014 at 9:20 PM, jcllings <jc...@gmail.com> wrote:
>> So It seems that:
>>
>> 1. There are indeed a few (3-4) mapping schemes.
>> 2. CQL isn't very hard and represents a subset of (ANSI?) SQ92.
>>
>> Both of these are validated based on further research and list guidance.
>>
>> It appears that learning Cassandra from an application developers
>> perspective essentially means learning what you can't do at all and
>> learning what you can't do directly that you could do with an RDMBS.
>> This and keys and maybe a thing or two about replication strategies and
>> you should be good to go. Does this seem accurate?
>>
>> What kinds of things would it be good to know for an interview?
>>
>> Jim C.
>>
>>
>
Re: Which way to Cassandraville?
Posted by jcllings <jc...@gmail.com>.
OK to clarify, I don't mean as an Administrator but an application
developer. If you use an ORM how important is CQL3? The object being
to eliminate any *QL from Java code.
Perhaps this technology isn't as mature as I thought.
Jim C.
On 07/22/2014 12:42 PM, DuyHai Doan wrote:
> "What kinds of things would it be good to know for an interview?"
>
> The underlying storage engine and how CQL3 maps to it. It's more than
> important, it's crucial. Knowing what you do and what you can't with
> CQL3 is not sufficient.
>
>
>
>
> On Tue, Jul 22, 2014 at 9:20 PM, jcllings <jcllings@gmail.com
> <ma...@gmail.com>> wrote:
>
> So It seems that:
>
> 1. There are indeed a few (3-4) mapping schemes.
> 2. CQL isn't very hard and represents a subset of (ANSI?) SQ92.
>
> Both of these are validated based on further research and list
> guidance.
>
> It appears that learning Cassandra from an application developers
> perspective essentially means learning what you can't do at all and
> learning what you can't do directly that you could do with an RDMBS.
> This and keys and maybe a thing or two about replication
> strategies and
> you should be good to go. Does this seem accurate?
>
> What kinds of things would it be good to know for an interview?
>
> Jim C.
>
>
Re: Which way to Cassandraville?
Posted by DuyHai Doan <do...@gmail.com>.
"What kinds of things would it be good to know for an interview?"
The underlying storage engine and how CQL3 maps to it. It's more than
important, it's crucial. Knowing what you do and what you can't with CQL3
is not sufficient.
On Tue, Jul 22, 2014 at 9:20 PM, jcllings <jc...@gmail.com> wrote:
> So It seems that:
>
> 1. There are indeed a few (3-4) mapping schemes.
> 2. CQL isn't very hard and represents a subset of (ANSI?) SQ92.
>
> Both of these are validated based on further research and list guidance.
>
> It appears that learning Cassandra from an application developers
> perspective essentially means learning what you can't do at all and
> learning what you can't do directly that you could do with an RDMBS.
> This and keys and maybe a thing or two about replication strategies and
> you should be good to go. Does this seem accurate?
>
> What kinds of things would it be good to know for an interview?
>
> Jim C.
>
>
Re: Which way to Cassandraville?
Posted by Robert Stupp <sn...@snazy.de>.
You can also try http://caffinitas.org - Open Source Java object mapper for C* using Datastax's Java Driver licensed using APL2. It is intended to be a bit close to what JPA does.
Although, it cannot support JPA features 1:1 since there are fundamental differences between RDBMS and NoSQL/C*.
But it has other features that traditional RDBMS do not have.
CQL in general is relatively close to SQL ("CQL is SQL minus joins and subqueries, plus collections") - with C* 2.1 you can add "plus user types"
Regarding an interview:
1. knowledge of query-driven data model
2. knowledge of C* cluster organization / how data is distributed
3. knowledge of consistency (levels)
4. knowledge of C* read and write path
Robert
Am 22.07.2014 um 21:20 schrieb jcllings <jc...@gmail.com>:
> So It seems that:
>
> 1. There are indeed a few (3-4) mapping schemes.
> 2. CQL isn't very hard and represents a subset of (ANSI?) SQ92.
>
> Both of these are validated based on further research and list guidance.
>
> It appears that learning Cassandra from an application developers
> perspective essentially means learning what you can't do at all and
> learning what you can't do directly that you could do with an RDMBS.
> This and keys and maybe a thing or two about replication strategies and
> you should be good to go. Does this seem accurate?
>
> What kinds of things would it be good to know for an interview?
>
> Jim C.
>
Re: Which way to Cassandraville?
Posted by jcllings <jc...@gmail.com>.
So It seems that:
1. There are indeed a few (3-4) mapping schemes.
2. CQL isn't very hard and represents a subset of (ANSI?) SQ92.
Both of these are validated based on further research and list guidance.
It appears that learning Cassandra from an application developers
perspective essentially means learning what you can't do at all and
learning what you can't do directly that you could do with an RDMBS.
This and keys and maybe a thing or two about replication strategies and
you should be good to go. Does this seem accurate?
What kinds of things would it be good to know for an interview?
Jim C.
Re: Which way to Cassandraville?
Posted by DuyHai Doan <do...@gmail.com>.
The problem with Hibernate and the kind is that they try to do many thing
at once. And support for JOINS bring a damned lots of complexity. You need
to manage object graphs and circular references -> statefull session ->
not thread-safe -> not good fit for async & multi threaded envs
On Tue, Jul 22, 2014 at 11:56 PM, Robert Stupp <sn...@snazy.de> wrote:
> True - Hibernate, Eclipselink and others add plenty of "synchronization"
> overhead owed the fact that an entity instance does not need to be
> explicitly persisted to get persisted (just change the loaded instance and
> flush the session). That's very expensive (CPU and heap). Even though
> transaction synchronization adds another cost.
>
> Pure mapping as itself is not really expensive compared to what one would
> do to return a Pojo or persist a Pojo. Take a look at
> https://bitbucket.org/snazy/caffinitas/ -
> PersistenceSessionImpl.loadOne()/insert() add not much overhead during
> runtime - but you get the object "ready to use".
>
>
> PS We are doing several million requests per day with Hibernate - but I
> spent a lot of work to optimize "framework" between business logic and JPA.
> It would not work "out of the box".
>
>
> Am 22.07.2014 um 23:32 schrieb Michael Dykman <md...@gmail.com>:
>
> > Removing *QL from application code is not really an indicator of the
> > maturity of a technology. ORMs and automatic type mapping in general
> > tend to be very easy things for a developer to work with allowing for
> > rapid prototypes, but those applications are often ill-suited to being
> > deployed is high-volume environments.
> >
> > I have used a wide variety of ORMs over the last 15 years, hibernate
> > being a favourite at which I am held to have some expertise, but when
> > I am creating an app for the real world in situations where I can
> > expect several million requests/day, I do not touch them.
> >
> >
> > On Tue, Jul 22, 2014 at 5:10 PM, Jake Luciani <ja...@gmail.com> wrote:
> >> Checkout datastax devcenter which is a GUI datamodelling tool for cql3
> >>
> >> http://www.datastax.com/what-we-offer/products-services/devcenter
> >>
> >>
> >> On Sun, Jul 20, 2014 at 7:17 PM, jcllings <jc...@gmail.com> wrote:
> >>>
> >>> So I'm a Java application developer and I'm trying to find entry points
> >>> for learning to work with Cassandra.
> >>> I just finished reading "Cassandra: The Definitive Guide" which seems
> >>> pretty out of date and while very informative as to the technology that
> >>> Cassandra uses, was not very helpful from the perspective of an
> >>> application developer.
> >>>
> >>> Having said that, what Java clients should I be looking at? Are there
> >>> any reasonably mature PoJo mapping techs for Cassandra analogous to
> >>> Hibernate? I can't say that I'm looking forward to yet another *QL
> >>> variant but I guess CQL is going to be a necessity. What, if any, GUI
> >>> tools are available for working with Cassandra, for data modelling?
> >>>
> >>> Jim C.
> >>>
> >>
> >>
> >>
> >> --
> >> http://twitter.com/tjake
> >
> >
> >
> > --
> > - michael dykman
> > - mdykman@gmail.com
> >
> > May the Source be with you.
>
>
Re: Which way to Cassandraville?
Posted by Robert Stupp <sn...@snazy.de>.
True - Hibernate, Eclipselink and others add plenty of "synchronization" overhead owed the fact that an entity instance does not need to be explicitly persisted to get persisted (just change the loaded instance and flush the session). That's very expensive (CPU and heap). Even though transaction synchronization adds another cost.
Pure mapping as itself is not really expensive compared to what one would do to return a Pojo or persist a Pojo. Take a look at https://bitbucket.org/snazy/caffinitas/ - PersistenceSessionImpl.loadOne()/insert() add not much overhead during runtime - but you get the object "ready to use".
PS We are doing several million requests per day with Hibernate - but I spent a lot of work to optimize "framework" between business logic and JPA. It would not work "out of the box".
Am 22.07.2014 um 23:32 schrieb Michael Dykman <md...@gmail.com>:
> Removing *QL from application code is not really an indicator of the
> maturity of a technology. ORMs and automatic type mapping in general
> tend to be very easy things for a developer to work with allowing for
> rapid prototypes, but those applications are often ill-suited to being
> deployed is high-volume environments.
>
> I have used a wide variety of ORMs over the last 15 years, hibernate
> being a favourite at which I am held to have some expertise, but when
> I am creating an app for the real world in situations where I can
> expect several million requests/day, I do not touch them.
>
>
> On Tue, Jul 22, 2014 at 5:10 PM, Jake Luciani <ja...@gmail.com> wrote:
>> Checkout datastax devcenter which is a GUI datamodelling tool for cql3
>>
>> http://www.datastax.com/what-we-offer/products-services/devcenter
>>
>>
>> On Sun, Jul 20, 2014 at 7:17 PM, jcllings <jc...@gmail.com> wrote:
>>>
>>> So I'm a Java application developer and I'm trying to find entry points
>>> for learning to work with Cassandra.
>>> I just finished reading "Cassandra: The Definitive Guide" which seems
>>> pretty out of date and while very informative as to the technology that
>>> Cassandra uses, was not very helpful from the perspective of an
>>> application developer.
>>>
>>> Having said that, what Java clients should I be looking at? Are there
>>> any reasonably mature PoJo mapping techs for Cassandra analogous to
>>> Hibernate? I can't say that I'm looking forward to yet another *QL
>>> variant but I guess CQL is going to be a necessity. What, if any, GUI
>>> tools are available for working with Cassandra, for data modelling?
>>>
>>> Jim C.
>>>
>>
>>
>>
>> --
>> http://twitter.com/tjake
>
>
>
> --
> - michael dykman
> - mdykman@gmail.com
>
> May the Source be with you.
Re: Which way to Cassandraville?
Posted by Michael Dykman <md...@gmail.com>.
Removing *QL from application code is not really an indicator of the
maturity of a technology. ORMs and automatic type mapping in general
tend to be very easy things for a developer to work with allowing for
rapid prototypes, but those applications are often ill-suited to being
deployed is high-volume environments.
I have used a wide variety of ORMs over the last 15 years, hibernate
being a favourite at which I am held to have some expertise, but when
I am creating an app for the real world in situations where I can
expect several million requests/day, I do not touch them.
On Tue, Jul 22, 2014 at 5:10 PM, Jake Luciani <ja...@gmail.com> wrote:
> Checkout datastax devcenter which is a GUI datamodelling tool for cql3
>
> http://www.datastax.com/what-we-offer/products-services/devcenter
>
>
> On Sun, Jul 20, 2014 at 7:17 PM, jcllings <jc...@gmail.com> wrote:
>>
>> So I'm a Java application developer and I'm trying to find entry points
>> for learning to work with Cassandra.
>> I just finished reading "Cassandra: The Definitive Guide" which seems
>> pretty out of date and while very informative as to the technology that
>> Cassandra uses, was not very helpful from the perspective of an
>> application developer.
>>
>> Having said that, what Java clients should I be looking at? Are there
>> any reasonably mature PoJo mapping techs for Cassandra analogous to
>> Hibernate? I can't say that I'm looking forward to yet another *QL
>> variant but I guess CQL is going to be a necessity. What, if any, GUI
>> tools are available for working with Cassandra, for data modelling?
>>
>> Jim C.
>>
>
>
>
> --
> http://twitter.com/tjake
--
- michael dykman
- mdykman@gmail.com
May the Source be with you.
Re: Which way to Cassandraville?
Posted by Jake Luciani <ja...@gmail.com>.
Checkout datastax devcenter which is a GUI datamodelling tool for cql3
http://www.datastax.com/what-we-offer/products-services/devcenter
On Sun, Jul 20, 2014 at 7:17 PM, jcllings <jc...@gmail.com> wrote:
> So I'm a Java application developer and I'm trying to find entry points
> for learning to work with Cassandra.
> I just finished reading "Cassandra: The Definitive Guide" which seems
> pretty out of date and while very informative as to the technology that
> Cassandra uses, was not very helpful from the perspective of an
> application developer.
>
> Having said that, what Java clients should I be looking at? Are there
> any reasonably mature PoJo mapping techs for Cassandra analogous to
> Hibernate? I can't say that I'm looking forward to yet another *QL
> variant but I guess CQL is going to be a necessity. What, if any, GUI
> tools are available for working with Cassandra, for data modelling?
>
> Jim C.
>
>
--
http://twitter.com/tjake
Re: Which way to Cassandraville?
Posted by jcllings <jc...@gmail.com>.
Correction, I mean vendor specific. Proprietary is OK so long as there
aren't any lock-in tricks or they can be dodged easy.
Jim C.
On 07/22/2014 12:12 PM, jcllings wrote:
> Does it have an annotation scheme or arrangement so I don't have to
> put proprietary stuff in my Java?
>
> Jim C.
>
> On 07/20/2014 06:24 PM, Kevin Burton wrote:
>>
>>
>> I just finished reading "Cassandra: The Definitive Guide" which seems
>> pretty out of date and while very informative as to the
>> technology that
>> Cassandra uses, was not very helpful from the perspective of an
>> application developer.
>>
>> Very very out of date…
>>
>>
>> Having said that, what Java clients should I be looking at?
>>
>>
>> I'd recommend the Datastax Java Driver. Works really well for us and
>> if you're familiar with JDBC it will be easy to get up and running fast.
>>
>> They are supporting it pretty aggressively too… the custom data type
>> stuff is already supported in 2.1.
>>
>>
>> Are there
>> any reasonably mature PoJo mapping techs for Cassandra analogous to
>> Hibernate?
>>
>>
>> One was just posted to the list… I would say there are 2-3 … I posted
>> on the same question and there's a thread around my email address if
>> you want to search for it.
>>
>> I personally ended up writing my own that just used a velocity code
>> generator so I could control the byte code output easily.
>>
>>
>>
>> I can't say that I'm looking forward to yet another *QL
>> variant but I guess CQL is going to be a necessity.
>>
>>
>> It's very close to an abbreviated SQL92 with a few less features.
>>
>> You won't have a problem.
>>
>>
>> --
>> Founder/CEO Spinn3r.com <http://Spinn3r.com>
>> Location: *San Francisco, CA*
>> blog:* *http://burtonator.wordpress.com
>> … or check out my Google+ profile
>> <https://plus.google.com/102718274791889610666/posts>
>> <http://spinn3r.com>
>
Re: Which way to Cassandraville?
Posted by jcllings <jc...@gmail.com>.
Does it have an annotation scheme or arrangement so I don't have to put
proprietary stuff in my Java?
Jim C.
On 07/20/2014 06:24 PM, Kevin Burton wrote:
>
>
> I just finished reading "Cassandra: The Definitive Guide" which seems
> pretty out of date and while very informative as to the technology
> that
> Cassandra uses, was not very helpful from the perspective of an
> application developer.
>
> Very very out of date…
>
>
> Having said that, what Java clients should I be looking at?
>
>
> I'd recommend the Datastax Java Driver. Works really well for us and
> if you're familiar with JDBC it will be easy to get up and running fast.
>
> They are supporting it pretty aggressively too… the custom data type
> stuff is already supported in 2.1.
>
>
> Are there
> any reasonably mature PoJo mapping techs for Cassandra analogous to
> Hibernate?
>
>
> One was just posted to the list… I would say there are 2-3 … I posted
> on the same question and there's a thread around my email address if
> you want to search for it.
>
> I personally ended up writing my own that just used a velocity code
> generator so I could control the byte code output easily.
>
>
>
> I can't say that I'm looking forward to yet another *QL
> variant but I guess CQL is going to be a necessity.
>
>
> It's very close to an abbreviated SQL92 with a few less features.
>
> You won't have a problem.
>
>
> --
> Founder/CEO Spinn3r.com <http://Spinn3r.com>
> Location: *San Francisco, CA*
> blog:* *http://burtonator.wordpress.com
> … or check out my Google+ profile
> <https://plus.google.com/102718274791889610666/posts>
> <http://spinn3r.com>
Re: Which way to Cassandraville?
Posted by Kevin Burton <bu...@spinn3r.com>.
>
>
> I just finished reading "Cassandra: The Definitive Guide" which seems
> pretty out of date and while very informative as to the technology that
> Cassandra uses, was not very helpful from the perspective of an
> application developer.
>
> Very very out of date…
> Having said that, what Java clients should I be looking at?
I'd recommend the Datastax Java Driver. Works really well for us and if
you're familiar with JDBC it will be easy to get up and running fast.
They are supporting it pretty aggressively too… the custom data type stuff
is already supported in 2.1.
> Are there
> any reasonably mature PoJo mapping techs for Cassandra analogous to
> Hibernate?
One was just posted to the list… I would say there are 2-3 … I posted on
the same question and there's a thread around my email address if you want
to search for it.
I personally ended up writing my own that just used a velocity code
generator so I could control the byte code output easily.
> I can't say that I'm looking forward to yet another *QL
> variant but I guess CQL is going to be a necessity.
It's very close to an abbreviated SQL92 with a few less features.
You won't have a problem.
--
Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile
<https://plus.google.com/102718274791889610666/posts>
<http://spinn3r.com>