Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Named params #56

Closed
wants to merge 5 commits into
from

Conversation

Projects
None yet
2 participants

dokipen commented Jun 17, 2012

Spent a few hours on this. My first problem was I'm using cql2, so when I tried some code on cql3 I realized that single-quoting identifiers (column names, column family names, etc.) is no longer valid(bummer). They should be double-quoted or not quoted at all. Since I require this behavior in my client code, I had to add a way to use double-quotes in parameters.

So I added the '#' positional parameter to the existing set, which will be double quoted.

For named parameters, you can use ':' for double-quoted values and '::' for single-quoted. Everything is backward compatible. The downside of this is that Connection.prototype.cql has to assume that if only one Object argument is passed, it is an options argument. This means that you can't use named parameters without also passing an options argument. Possible ways around this are (1) make a new function, (2) break backward compatibility, (3) accept named parameters in cql() using a single parameter object (optionally), or (4) analyze the cmd to see if it expects named parameters, doing something intelligent.

I didn't realize I'd need the double-quote functionality until after I had already written the named parameter code, so it's all in one commit. I can break it up upon request.

dokipen commented Jun 17, 2012

Another approach to this entire thing is to parse the queries an intelligently use the right quoting depending on position. Obviously, this would require a lot more code. I'd like to keep things simple. I think it's acceptable to let the client decide how parameters should be quoted.

Owner

devdazed commented Jul 9, 2012

hey, sorry about not getting to this sooner, we've been swamped. Can you update the pull request so that it can be merged. Also, how does this work? Does it change the current API at all?

dokipen commented Jul 9, 2012

I've explained it all above. It is completely backwards compatible. I'll see if I can get to it within the next couple of days.

Owner

devdazed commented Jul 9, 2012

I mean't examples of usage that I can add to the readme.

dokipen commented Jul 9, 2012

ah, ok. I'll do that too.

@devdazed devdazed closed this May 6, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment