cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre Chalamet (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
Date Wed, 16 May 2012 06:46:14 GMT


Pierre Chalamet commented on CASSANDRA-4242:

bq. Well, yes, it's definitely designed around data sources that give you ordered values instead.
This fits at the least JDBC, Python DBAPI, and Ruby DBI. What are you using that can't work
with this paradigm?
There are basically 2 use cases:
* micro-orm like (mapping object to and from a query)
* feeding from external data source (like a rowset which usually support ordered and named

Version in trunk of cassandra-sharp (my cassandra .net client) support actually a micro-orm
interface (with this patch) - it is still under development but this will probably looks like

[Schema("TestKeyspace", Comment = "People table", Name="People")]
public class PeopleSchema
	[Index(Name = "birthyear")]
	public int Birthyear;

	[Key(Name = "firstname")]
	public string FirstName;

	[Column(Name = "lastname")]
	public string LastName;


cluster.Execute("insert into People (firstname, lastname, birthyear) values (?, ?, ?)",
                new {firstname = "pierre", lastname = "chalamet", birthyear = 1973});

I do not want this framework to be user driven (ie: the user provides the parameters and knows
the nitty gritty details of his query) - instead I want this framework to be query driven
for parameters feeding (ie: the query determines what is necessary to complete the execution).
This way, the user can change its query without changing the parameters order - it is still
the plain old .net object exposing unordered properties. You can refactor as you want the
query or the .net object, it should still work.

The other interface I'd like to setup in the micro-orm area is something like the on in Gigaspaces
(query template with plain old object) - the interface is really good for getting results.
For extended queries, it is also required to be able to map parameters.

The second use case is less obvious, but suppose I need to transfer data between a database
and C*.
I would select on one side and insert on the other side - using something like a data reader
in .net.
For that, I still do not want to rely on order of the column in the rowset - I would prefer
to discover the structure and bind parameters accordingly using a the data reader metadata
(basically column names).

I do believe it is good functionality client side. This will allow more way to interact with
C* in safer way without much cost anyway.
Compared to the cost of the i/o, retrieving the column names in CqlPreparedResult and mapping
client side is really cheap.

I've also read CASSANDRA-2474 - quite interesting thanks for the link. But I really would
prefer to have binary in column name instead of string. That's why in the new patch I did
not changed this. I'm not really clear on this, I had to think more about it, but as is, I
have the feeling that C* is moving away from sliced query on binary column names (a strong
feature in my opinion). It might does stand when considering hadoop, hive and co... I might
be the only guy using C* alone anyway.
Moreover, CqlMetadata exposes column names as binary - I would also prefer something symmetrical
(weak argument anyway).
> Name of parameters should be available in CqlPreparedResult
> -----------------------------------------------------------
>                 Key: CASSANDRA-4242
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.1.0
>            Reporter: Pierre Chalamet
>            Priority: Minor
>         Attachments: 4242.txt, 4242_2.txt
> Client side, it could be nice to have the name of parameters in CqlPreparedResult. This
could allow parameters mapping by name instead of by index.
> {code}
> struct CqlNameType {
>     1: required binary key,
> 	2: required string type
> }
> struct CqlPreparedResult {
>     1: required i32 itemId,
>     2: required i32 count,
>     3: optional list<string> variable_types,
>     4: optional list<CqlNameType> name_types
> }
> {code}

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message