[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276521#comment-13276521
]
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 columns).
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 this:
{code}
[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.Create<PeopleSchema>();
cluster.Execute("insert into People (firstname, lastname, birthyear) values (?,
?, ?)",
new {firstname = "pierre", lastname = "chalamet", birthyear =
1973});
{code}
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: https://issues.apache.org/jira/browse/CASSANDRA-4242
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
