Re: bug report - CQL3 grammar should ignore VARCHAR column length in CREATE statements
> When creating a table in all ANSI-SQL compliant RDBMS' the VARCHAR datatype > takes a numeric parameter, however this parameter is generating errors in > CQL3. > CQL3 is *not* ANSI-SQL compliant and will never be. It's not even SQL. > I would like to propose that the column length be allowed in the grammar > (but ignored by cassandra), allowing better ANSI-SQL client compatibility. > I agree with Ed and disagree with your proposal. Allowing a length constraint but not respecting it would only help people to shoot themselves in the foot, as they would be led to believe Cassandra does validate the length where it doesn't. If would be acceptable to add the length only if we do respect it. Which is something we could do, though adding it "just" to make it close to ANSI-SQL honestly doesn't interest me much (adding it because it's useful would be a better argument however) because again, CQL is not SQL. In particular, you don't model application with CQL the same way you do with SQL, and so using a SQL application in CQL without modification is not a good idea. Besides, I doubt any non-trivial SQL application could be used as is in CQL, due to the lack of join for instance. -- Sylvain
Re: cassandra-cli on cygwin
Go for it, although I think (1) might be cygwin being "helpful" and (2) means your classpath needs adjusting rather than moving .yaml files around. On Mon, Mar 4, 2013 at 1:00 AM, vck wrote: > just playing around with cassandra code after setting it up. > but on running cassandra-cli on cygwin, it gives me a couple of issues. > > 1) dos2unix has to be run on cassandra-cli and cassandra.in.sh > > 2) cassandra-cli gave following exception > * Exception in thread "main" org.yaml.snakeyaml.error.YAMLException: > java.io.IOException: Stream closed > * Fixed it by pasting CliHelp.yaml from > src/resources/org/apache/cassandra/cli to src/java/org/... > > 3) cygpath needs to be used to convert the dos CLASSPATH, added the > following to cassandra-cli. > > #case "`uname`" in > #CYGWIN*) > #CLASSPATH=`cygpath -p -w "$CLASSPATH"` > #;; > #esac > > > Probably this needs some documenting or correction in the script. could i > raise a jira request? > > thanks > ~vk -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
C* 1.2.2 vs Raspberry Pi
Stupidly I've locked myself out of JIRA and it doesn't seem to want to send me a password reset so I'll send this bug report here. As you guys may know I'v been running C* on a Raspberry Pi cluster for experimental and educational reasons. It seems the startup script is borked for 1.2.2 when using JDK1.8 (early release) on the PI. In Cassandra-env.sh lines 206-208 if [ "$JVM_VERSION" \> "1.7" ] ; then JVM_OPTS="$JVM_OPTS -XX:+UseCondCardMark" fi Are causing C* to not start on the Pi. It's reporting : Unrecognized VM option 'UseCondCardMark' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. It looks like this change came in for 1.2.2 Andy Cobley School of Computing University of Dundee The University of Dundee is a registered Scottish Charity, No: SC015096
Re: C* 1.2.2 vs Raspberry Pi
This was due to https://issues.apache.org/jira/browse/CASSANDRA-4366 Should be safe to remove this when running on a you Raspberry Pi as it is a performance change for the JVM and I guess not supported on whatever version is supported on your distro for the Pi. -mike On 3/4/13 11:17 AM, "Andrew Cobley" wrote: >Stupidly I've locked myself out of JIRA and it doesn't seem to want to >send me a password reset so I'll send this bug report here. > >As you guys may know I'v been running C* on a Raspberry Pi cluster for >experimental and educational reasons. It seems the startup script is >borked for 1.2.2 when using JDK1.8 (early release) on the PI. > >In Cassandra-env.sh lines 206-208 > >if [ "$JVM_VERSION" \> "1.7" ] ; then >JVM_OPTS="$JVM_OPTS -XX:+UseCondCardMark" >fi > >Are causing C* to not start on the Pi. It's reporting : > >Unrecognized VM option 'UseCondCardMark' >Error: Could not create the Java Virtual Machine. >Error: A fatal exception has occurred. Program will exit. > >It looks like this change came in for 1.2.2 > >Andy Cobley >School of Computing >University of Dundee > > >The University of Dundee is a registered Scottish Charity, No: SC015096 > Copy, by Barracuda, helps you store, protect, and share all your amazing things. Start today: www.copy.com.
Re: C* 1.2.2 vs Raspberry Pi
Mike, I'll see if there is a conditionally way of removing it. It seems to be the jdk1.8 for arm (hard float) thats missing the option ATM so it could effect other ARM devices at some point. Andy On 4 Mar 2013, at 19:24, Michael Kjellman wrote: > This was due to > > https://issues.apache.org/jira/browse/CASSANDRA-4366 > > Should be safe to remove this when running on a you Raspberry Pi as it is > a performance change for the JVM and I guess not supported on whatever > version is supported on your distro for the Pi. > > -mike > > On 3/4/13 11:17 AM, "Andrew Cobley" wrote: > >> Stupidly I've locked myself out of JIRA and it doesn't seem to want to >> send me a password reset so I'll send this bug report here. >> >> As you guys may know I'v been running C* on a Raspberry Pi cluster for >> experimental and educational reasons. It seems the startup script is >> borked for 1.2.2 when using JDK1.8 (early release) on the PI. >> >> In Cassandra-env.sh lines 206-208 >> >> if [ "$JVM_VERSION" \> "1.7" ] ; then >> JVM_OPTS="$JVM_OPTS -XX:+UseCondCardMark" >> fi >> >> Are causing C* to not start on the Pi. It's reporting : >> >> Unrecognized VM option 'UseCondCardMark' >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> >> It looks like this change came in for 1.2.2 >> >> Andy Cobley >> School of Computing >> University of Dundee >> >> >> The University of Dundee is a registered Scottish Charity, No: SC015096 >> > > > Copy, by Barracuda, helps you store, protect, and share all your amazing > things. Start today: www.copy.com. > The University of Dundee is a registered Scottish Charity, No: SC015096
Re: C* 1.2.2 vs Raspberry Pi
It's an optimisation flag, and not applicable to the to the 1.x JVM's should be fine to remove it. --Jools On 4 March 2013 19:17, Andrew Cobley wrote: > Stupidly I've locked myself out of JIRA and it doesn't seem to want to > send me a password reset so I'll send this bug report here. > > As you guys may know I'v been running C* on a Raspberry Pi cluster for > experimental and educational reasons. It seems the startup script is > borked for 1.2.2 when using JDK1.8 (early release) on the PI. > > In Cassandra-env.sh lines 206-208 > > if [ "$JVM_VERSION" \> "1.7" ] ; then > JVM_OPTS="$JVM_OPTS -XX:+UseCondCardMark" > fi > > Are causing C* to not start on the Pi. It's reporting : > > Unrecognized VM option 'UseCondCardMark' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > It looks like this change came in for 1.2.2 > > Andy Cobley > School of Computing > University of Dundee > > > The University of Dundee is a registered Scottish Charity, No: SC015096 > >
Re: C* 1.2.2 vs Raspberry Pi
Yep, I did remove it and all was well. However it is a gotcha for anyone trying C* on the Pi so a better solution is probably needed (conditionally removal) Andy On 4 Mar 2013, at 19:30, Jools wrote: > It's an optimisation flag, and not applicable to the to the 1.x JVM's > should be fine to remove it. > > --Jools > > > On 4 March 2013 19:17, Andrew Cobley wrote: > >> Stupidly I've locked myself out of JIRA and it doesn't seem to want to >> send me a password reset so I'll send this bug report here. >> >> As you guys may know I'v been running C* on a Raspberry Pi cluster for >> experimental and educational reasons. It seems the startup script is >> borked for 1.2.2 when using JDK1.8 (early release) on the PI. >> >> In Cassandra-env.sh lines 206-208 >> >> if [ "$JVM_VERSION" \> "1.7" ] ; then >>JVM_OPTS="$JVM_OPTS -XX:+UseCondCardMark" >> fi >> >> Are causing C* to not start on the Pi. It's reporting : >> >> Unrecognized VM option 'UseCondCardMark' >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> >> It looks like this change came in for 1.2.2 >> >> Andy Cobley >> School of Computing >> University of Dundee >> >> >> The University of Dundee is a registered Scottish Charity, No: SC015096 >> >> The University of Dundee is a registered Scottish Charity, No: SC015096
Re: bug report - CQL3 grammar should ignore VARCHAR column length in CREATE statements
Hi Sylvain, I disagree. Actually, CQL3 is really close to being a faithful subset of ANSI-SQL, which is rather exciting. This is just one of a few small adjustments that can be made to the grammar to make everyone's life easier while still maintaining the spirit of NOSQL. The semantics of how the grammar is implemented behind the scenes is unimportant, what matters more is that an an ANSI-like interface should have ANSI-like behavior where possible, if only for the greater good of humanity! Implementing a subset of ANSI is a good thing, changing ANSI-SQL not so much. On this specific issue, Cassandra's behavior subsumes what would be expected of say VARCHAR(256) or VARCHAR(MAX) so throwing an exception to client apps when they ask for either of these is incorrect. There are a handful of minor disparities whereby the ANSI spec has been changed (vs. not implemented) - I'm making a list of the former and I'll put it into JIRA under one task. ap On Mon, Mar 4, 2013 at 7:08 PM, Sylvain Lebresne wrote: > > When creating a table in all ANSI-SQL compliant RDBMS' the VARCHAR > datatype > > takes a numeric parameter, however this parameter is generating errors in > > CQL3. > > > > CQL3 is *not* ANSI-SQL compliant and will never be. It's not even SQL. > > > > > I would like to propose that the column length be allowed in the grammar > > (but ignored by cassandra), allowing better ANSI-SQL client > compatibility. > > > > I agree with Ed and disagree with your proposal. Allowing a length > constraint > but not respecting it would only help people to shoot themselves in the > foot, as > they would be led to believe Cassandra does validate the length where it > doesn't. > > If would be acceptable to add the length only if we do respect it. Which is > something we could do, though adding it "just" to make it close to ANSI-SQL > honestly doesn't interest me much (adding it because it's useful would be a > better argument however) because again, CQL is not SQL. In particular, you > don't model application with CQL the same way you do with SQL, and so using > a SQL application in CQL without modification is not a good idea. Besides, > I doubt any non-trivial SQL application could be used as is in CQL, due to > the > lack of join for instance. > > -- > Sylvain >
