Backbone.js: Collection doesn’t get pupulated trough its fetch() method from Cassandra

Sample fictional app domain:

Suppose I’m doing this great Tasks app for managing tasks, right..

The problem:

Backbone.js Collection doesn’t get correctly populated trough its fetch() method from Cassandra

So I basically got Tasks from Cassandra, got them (trough REST API) in Backbone and then…well nothing. Somewhere in “black magic” Backbone is doing with its collection-to-models calls, Tasks just disappeared. Whaaat?!

So to spice the soup a bit more, collection had 2 more symptoms:

  1. there was actually one model there (the last one from fetched data) and
  2. if I’d try to manually (from browser console) call create(new Task()) on Tasks collection the Task model would actually appear in Tasks collection


Well I noticed this strange hex field in my JSON(ed) data I got from server right. And I thought “well, I’ll solve that later, it’s not important now. Just do = id.hex instead of = id when getting value and that’s it” – DON’T EVER PASS BY SOMETHING THAT’S NOT ABSOLUTELY CLEAR TO YOU WHY IT’S THERE!

This piece of code was problematic:

someTaskArrayBeforeJsonized = {
    'id':        // C* datatype is UUID - problem
    'title': this.title  // C* datatype is VARCHAR - works OK

The solution:

The solution was simple, just add toString() to uuid fields you get from Cassandra. So the code would look like this;

someTaskArrayBeforeJsonized = {
    'id':    // C* datatype is UUID . work OK
    'title': this.title         // C* datatype is VARSHAR - works OK

That toString() up in the example saves you trouble of getting hex field in someTaskArrayBeforeJsonized upon JSONfiying.

It’s also worth noting I use Helenus driver for interfacing Node.js and Cassandra.

I’m not shure exactly who in the stack was the trouble maker..

  1. was the V8 JSON.stringify “not understanding” the uuid datatype he was gets from Helenus/Cassandra
  2. or maybe Helenus did some “black magic” on its end…

…who knows. I’m happy (for now) that it works. Maybe(big maybe) I’ll investigate this in the future or something.

Hope it helps someone. If you have some better ide why this is happening, comment plz, tnx.

If you are really into JSON then you should read this(it’s short) from

UPDATE 01: It’s obvious! Javascript doesn’t understand 2829c930-2e98-11e2-8b62-2519782d29d8 notation!! If you take better look at the format, it’s not of any JS known primitives, right?! So you have to convert it to (at least) String to make something useful with it… like == comparison etc. Mystery solved, enjoy.

UPDATE 02: If you’r working with UUIDs or other hex values in Javascript it’s probably the best way to just store string representation of the field along side the original value. So for id store id_str along so you don’t have to parse it at runtime, right. It works for Twitter – take a peek at their home_timeline json api and search for id_str.

The real revolution will come when we have research engines

Forget search engines. The real revolution will come when we have research engines, intelligent Web helpers that can find out new things, not just what’s already been written. Facebook Graph Search isn’t anywhere near that good, but it’s a nice hint at greater things to come.

Gary Marcus

He’s got the looks, he’s great at playing the part

Here is one great advice for talent as well as job seekers from movie (and book) Moneyball:

He passes the eye candy test. He’s got the looks, he’s great at playing the part.

Spectacular startup success often becomes a game about scouting and recruiting. A common mistake entrepreneurs make is recruiting team members early on simply becausethey look the part. In the long run, it doesn’t matter if on paper, someone’s perfect. You want people that can actually do the job. That VP of Sales candidate that has 15 years of experience at Oracle? Likely not worth it for you. They’ll look the part, but they may not be able to deliver the goods. And, like Johnny Damon, she’s going to be expensive.

Get good at seeing talent where others don’t.