[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13447531#comment-13447531
]
Sylvain Lebresne commented on CASSANDRA-4594:
---------------------------------------------
bq. This is because a select * from airplanes; does not give the columns in the
order they were defined.
No it doesn't. The vaguely technical reason is that we don't keep internally
the order of definition of columns, so we would have to start keeping that
information (which honestly wouldn't be that much of a burden now that we have
the list support, but was a tad more annoying to do at the time I wrote the
code for select *). And I think that it's one place where it's not worth
committing to any specific order but rather left it unspecified, so I don't see
the point in bothering to record said definition order.
For the record though, the order of * is not completely random. It returns
first the columns composing the PK (in the order of the PK) and then the rest
of the columns in lexicographic order. But really it's mostly because it's
convenient for the implementation to do it that way.
> COPY TO and COPY FROM don't default to consistent ordering of columns
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-4594
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
> Project: Cassandra
> Issue Type: Bug
> Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
> Reporter: Tyler Patterson
> Assignee: paul cannon
> Priority: Minor
> Fix For: 1.2.0
>
>
> Here is the input:
> {code}
> CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
> strategy_options:replication_factor = 1;
> USE test;
>
>
>
> CREATE TABLE airplanes (
>
> name text PRIMARY KEY,
>
> manufacturer ascii,
>
> year int,
>
> mach float
>
> );
>
>
>
> INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
> ('P38-Lightning', 'Lockheed', 1937, '.7');
>
>
> COPY airplanes TO 'temp.cfg' WITH HEADER=true;
>
>
>
> TRUNCATE airplanes;
>
>
>
> COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
>
>
>
> SELECT * FROM airplanes;
> {code}
> Here is what happens when executed. Note how it tried to import the float
> into the int column:
> {code}
> cqlsh:test> DROP KEYSPACE test;
>
> cqlsh:test> CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
> strategy_options:replication_factor = 1;
> cqlsh:test> USE test;
>
> cqlsh:test>
>
> cqlsh:test> CREATE TABLE airplanes (
>
> ... name text PRIMARY KEY,
>
> ... manufacturer ascii,
>
> ... year int,
>
> ... mach float
>
> ... );
>
> cqlsh:test>
>
> cqlsh:test> INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
> ('P38-Lightning', 'Lockheed', 1937, '.7');
> cqlsh:test>
>
> cqlsh:test> COPY airplanes TO 'temp.cfg' WITH HEADER=true;
>
> 1 rows exported in 0.003 seconds.
>
> cqlsh:test> TRUNCATE airplanes;
>
> cqlsh:test>
>
> cqlsh:test> COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
>
> Bad Request: unable to make int from '0.7'
>
> Aborting import at record #0 (line 1). Previously-inserted values still
> present.
> 0 rows imported in 0.002 seconds.
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
