Re: Document storage
On Wed, Mar 28, 2012 at 6:59 PM, Jeremiah Jordan jeremiah.jor...@morningstar.com wrote: Sounds interesting to me. I looked into adding protocol buffer support at one point, and it didn't look like it would be too much work. The tricky part was I also wanted to add indexing support for attributes of the inserted protocol buffers. That looked a little trickier, but still not impossible. Though other stuff came up and I never got around to actually writing any code. JSON support would be nice, especially if you figured out how to get built in indexing of the attributes inside the JSON to work =). Also, for whatever it's worth, it should be trivial to add support for Smile (binary JSON serialization): http://wiki.fasterxml.com/SmileFormatSpec since its logical data structure is pure JSON, no extensions or subsetting. The main Java impl is by Jackson project, but there is also a C codec (https://github.com/pierre/libsmile), and prototypes for PHP and Ruby bindings as well. But for all data it's bit faster, bit more compact; about 30% for individual items, but more (40 - 70%) for data sequences (due to optional back-referencing). JSON and Smile can be auto-detected from first 4 bytes or so, reliably and efficiently, so one should be able to add this either transparently or explicitly. One could even transcode things on the fly -- store as Smile, expose filtered results as JSON (and accept JSON or both). This could reduce storage cost while keep the benefits of flexible data format. -+ Tatu +-
Re: What's the point of the deviation of java code style in Cassandra?
On Fri, Jan 27, 2012 at 4:05 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: You perhaps are not a veteran of the braces wars of 1973-2011... Please don't try to start them up again! Every project has its own style. Stick to that style. +1 known as the When in Rome... convention. -+ Tatu +-
Re: What's the point of the deviation of java code style in Cassandra?
On Fri, Jan 27, 2012 at 3:18 PM, bxqdev bxq...@themailbay.com wrote: i guess that's what nazis cited to jews in 30's ;) Ok everyone -- it's now ok to stop the discussion, as per Godwin's law! [http://en.wikipedia.org/wiki/Godwin%27s_law] -+ Tatu +-
Re: Implementing queue in Cassandra
On Wed, Jan 18, 2012 at 7:31 AM, Eric Martell workoutexc...@yahoo.com wrote: Hi, I am having 10 millions of rows with in sql db in key table. key_id - key_value For each request I am fetching one key_id and removing that from the key table. Each request should get unique key_id. Similar to java queue but keys persists in DB. How do I implement that in Cassandra and what is the best way to achieve this? Why Cassandra and not a real queue implementation? My first advice would usually be just don't, since deletion is done by tombstoning. What may work better is store payload in Cassandra and send ids separately; this is how we did a queueing system with AWS (SQS for passing ids, S3 for storing payload) -+ Tatu +-
Re: major version release schedule
On Tue, Dec 20, 2011 at 6:16 AM, Jonathan Ellis jbel...@gmail.com wrote: Nobody's forcing you to upgrade. If you want twice as much time between upgrading, just wait for 1.2. In the meantime, people who need the features in 1.1 also get those early (no, running trunk in production isn't a serious option). I don't see any real benefit for you in forcing your preference on everyone, and I see a big negative for some. It's also worth noting that waiting for 2x as many features for freeze will result in MORE than 2x as much complexity for tracking down regressions. Given the limited testing we get during freeze, I think that's a pretty strong argument in favor of more-frequent, smaller releases. +1. I really don't see why anyone would feel forced to upgrade just because a new version is available. -+ Tatu +-
