Re: Which way to Cassandraville?

[Robert Coli]

On Tue, Jul 22, 2014 at 1:10 PM, Russell Bradberry 
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?

[DuyHai Doan]

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  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 :
>
> > 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  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  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
> > - mdyk...@gmail.com
> >
> > May the Source be with you.
>
>

Re: Which way to Cassandraville?

[Robert Stupp]

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 :

> 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  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  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
> - mdyk...@gmail.com
> 
> May the Source be with you.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Which way to Cassandraville?

[Michael Dykman]

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  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  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
 - mdyk...@gmail.com

 May the Source be with you.

Re: Which way to Cassandraville?

[Jake Luciani]

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

[jcllings]

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.



signature.asc
Description: OpenPGP digital signature

Re: Which way to Cassandraville?

[Robert Stupp]

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 :

> "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  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. 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Which way to Cassandraville?

[DuyHai Doan]

"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  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?

[jcllings]

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.


signature.asc
Description: OpenPGP digital signature

Re: Which way to Cassandraville?

[Robert Stupp]

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 :

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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Which way to Cassandraville?

[Russell Bradberry]

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 (jclli...@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  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?

[jcllings]

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



signature.asc
Description: OpenPGP digital signature

Re: Which way to Cassandraville?

[Robert Stupp]

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 :

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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Which way to Cassandraville?

[DuyHai Doan]

"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  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?

[jcllings]

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.



signature.asc
Description: OpenPGP digital signature

Re: Which way to Cassandraville?

[jcllings]

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 
>> Location: *San Francisco, CA*
>> blog:* *http://burtonator.wordpress.com
>> … or check out my Google+ profile
>> 
>> 
>



signature.asc
Description: OpenPGP digital signature

Re: Which way to Cassandraville?

[jcllings]

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 
> Location: *San Francisco, CA*
> blog:* *http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: Which way to Cassandraville?

[DuyHai Doan]

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

[Kevin Burton]

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

Which way to Cassandraville?

[jcllings]

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.



signature.asc
Description: OpenPGP digital signature