Mutagen for Cassandra
We are looking for a schema upgrade management tool for Cassandra. Does anyone have any experience using mutagen for Casssandra in a production environment? Any other recommendations?
CQL collections and Solr dynamic fields
In the DSE 4.7 advanced tutorial, there is an example of using a CQL map together with Solr dynamic fields, so that every map entry is automatically indexed by Solr. Does this work for the other CQL collections, namely lists and sets? Can I define CQL lists and sets to use Solr dynamic fields, so they are automatically indexed by Solr?
Re: CQL collections and Solr dynamic fields
Lists and sets are implemented as multivalue fields, and dse solr does not support dynamic multivalue fields. Therefore, I conclude that dse solr does not support dynamic field search for sets and lists, I. E. I will have to modify the solr schema and re-index each time I add a new CQL llist or set. Is my logic correct? On Monday, June 22, 2015, Jack Krupansky jack.krupan...@gmail.com wrote: List and set collections are mapped to multivalued Solr fields - a Solr query will match on any of the values in a multivalued Solr field (or keywords within those multiple values for Solr tokenized text fields.) See: http://docs.datastax.com/en/datastax_enterprise/4.7//datastax_enterprise/srch/srchSolrType.html -- Jack Krupansky On Mon, Jun 22, 2015 at 4:32 AM, Moshe Kranc moshekr...@gmail.com javascript:_e(%7B%7D,'cvml','moshekr...@gmail.com'); wrote: In the DSE 4.7 advanced tutorial, there is an example of using a CQL map together with Solr dynamic fields, so that every map entry is automatically indexed by Solr. Does this work for the other CQL collections, namely lists and sets? Can I define CQL lists and sets to use Solr dynamic fields, so they are automatically indexed by Solr?
DSE 4.7 security
The DSE 4.7 documentation says: You use the familiar relational database GRANT/REVOKE paradigm to grant or revoke permissions to access Cassandra data. Does this mean authorization is per table? What if I need finer grain authorization, e.g., per row or even per cell (e.g., a specific column in a specific row may not be seen by users in a group)? Do I need to implement this in my application, because Cassandra does not support it?
RE: Viewing Cassandra's Internal table Structure in a CQL world
Yes, cassandra-cli still works. But it also tells me that I should switch to CQL, and it doesn't want to display CQL3 tables. My question isn't how to get the info today – it's whether that info will still be available in the future. From: DuyHai Doan [mailto:doanduy...@gmail.com] Sent: Wednesday, May 13, 2015 10:40 PM To: user@cassandra.apache.org Subject: Re: Viewing Cassandra's Internal table Structure in a CQL world I think that you can still use cassandra-cli from 2.0.x to look into internal table structure. Of course you will see bytes instead of readable values but it's better than nothing. It's already the case for CQL collections when you're trying to decode them using cassandra-cli On Wed, May 13, 2015 at 9:27 PM, Moshe Kranc moshekr...@gmail.com mailto:moshekr...@gmail.com wrote: CQL is the future, and it provides a great high-level view of keyspaces. (I am drinking the Kool-Aid.) But, I believe every C* developer needs to also look at the table's internal structure, e.g., what do the column names actually look like. Only by keeping an eye on the physical structure can you tune your queries for best performance. To date, I have been using cassandra-cli to view the table's internal structure. But, I get bombarded with all kinds of warnings about how I should switch to CQL and stop using a deprecated product. My question: After the revolution (once Cassandra-cli has been retired), how am I supposed to look at the table's internal structure? Or, do you believe that ultimately there will be no need or value in looking at the internal structure? (I would disagree.)
Viewing Cassandra's Internal table Structure in a CQL world
CQL is the future, and it provides a great high-level view of keyspaces. (I am drinking the Kool-Aid.) But, I believe every C* developer needs to also look at the table's internal structure, e.g., what do the column names actually look like. Only by keeping an eye on the physical structure can you tune your queries for best performance. To date, I have been using cassandra-cli to view the table's internal structure. But, I get bombarded with all kinds of warnings about how I should switch to CQL and stop using a deprecated product. My question: After the revolution (once Cassandra-cli has been retired), how am I supposed to look at the table's internal structure? Or, do you believe that ultimately there will be no need or value in looking at the internal structure? (I would disagree.)
