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