Re: Request for reviewer: CASSANDRA-14829
Hi Georg, I took a look at your patch and left some comments on the ticket. Thanks, Dinesh On Friday, November 16, 2018, 12:04:39 PM PST, Jeff Jirsa wrote: The assignment is just so you get “credit” for the patch - asking for a reviewer is good but not strictly necessary. (Some of the committers will try to review it when we can, usually waiting for someone who’s comfortable with that code to come along) -- Jeff Jirsa > On Nov 16, 2018, at 11:33 AM, Georg Dietrich wrote: > > Hi here, > > I've posted https://issues.apache.org/jira/browse/CASSANDRA-14829 together > with a pull request, now I've been assigned the task... I assume that means I > should go look for a reviewer? > > Regards > Georg > > -- > > Georg Dietrich > Senior System Developer > imbus TestBench > Tel. +49 9131 7518-944 > E-Mail: georg.dietr...@imbus.de > > Tel. +49 9131 7518-0, Fax +49 9131 7518-50 > i...@imbus.de www.imbus.de > > imbus AG, Kleinseebacher Str. 9, 91096 Möhrendorf, DEUTSCHLAND > Vorsitzender des Aufsichtsrates: Wolfgang Wieser > Vorstand: Tilo Linz, Bernd Nossem, Thomas Roßner > Sitz der Gesellschaft: Möhrendorf; Registergericht: Fürth/Bay, HRB 8365 > > Post/Besuchsadresse: imbus AG, Hauptstraße 8a, 91096 Möhrendorf, Deutschland > = > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Request for reviewer: CASSANDRA-14829
The assignment is just so you get “credit” for the patch - asking for a reviewer is good but not strictly necessary. (Some of the committers will try to review it when we can, usually waiting for someone who’s comfortable with that code to come along) -- Jeff Jirsa > On Nov 16, 2018, at 11:33 AM, Georg Dietrich wrote: > > Hi here, > > I've posted https://issues.apache.org/jira/browse/CASSANDRA-14829 together > with a pull request, now I've been assigned the task... I assume that means I > should go look for a reviewer? > > Regards > Georg > > -- > > Georg Dietrich > Senior System Developer > imbus TestBench > Tel. +49 9131 7518-944 > E-Mail: georg.dietr...@imbus.de > > Tel. +49 9131 7518-0, Fax +49 9131 7518-50 > i...@imbus.de www.imbus.de > > imbus AG, Kleinseebacher Str. 9, 91096 Möhrendorf, DEUTSCHLAND > Vorsitzender des Aufsichtsrates: Wolfgang Wieser > Vorstand: Tilo Linz, Bernd Nossem, Thomas Roßner > Sitz der Gesellschaft: Möhrendorf; Registergericht: Fürth/Bay, HRB 8365 > > Post/Besuchsadresse: imbus AG, Hauptstraße 8a, 91096 Möhrendorf, Deutschland > = > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Request for reviewer: CASSANDRA-14829
Hi here, I've posted https://issues.apache.org/jira/browse/CASSANDRA-14829 together with a pull request, now I've been assigned the task... I assume that means I should go look for a reviewer? Regards Georg -- Georg Dietrich Senior System Developer imbus TestBench Tel. +49 9131 7518-944 E-Mail: georg.dietr...@imbus.de Tel. +49 9131 7518-0, Fax +49 9131 7518-50 i...@imbus.de www.imbus.de imbus AG, Kleinseebacher Str. 9, 91096 Möhrendorf, DEUTSCHLAND Vorsitzender des Aufsichtsrates: Wolfgang Wieser Vorstand: Tilo Linz, Bernd Nossem, Thomas Roßner Sitz der Gesellschaft: Möhrendorf; Registergericht: Fürth/Bay, HRB 8365 Post/Besuchsadresse: imbus AG, Hauptstraße 8a, 91096 Möhrendorf, Deutschland =
RE : issue while connecting to apache-cassandra-3.11.1 hosted on a remote VM.
Hi, Whenever I am trying to connect to apache-cassandra-3.11.1, I am getting exception Unexpected client failure - null The detailed explanation : JMXConnectionPool.getJMXConnection - Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host:; nested exception is: java.net.ConnectException: Connection refused (Connection refused)] I tried following workaround 1) Adding IP Address of the machine (where server is installed) in /etc/hosts (For Linux OS) 2) Adding IP Address of the machine (where server is installed) in cassandra.yaml (entry as seed and listen addresses) 3)Also check for proper variables are set for java and Cassandra. However, while executing the "netstat -an | grep 7199" command ,I am still getting the 127.0.0.1 as the hosted ip. Can you suggest me any change which needs to be done in the configuration or the connection mechanism of apache-cassandra-3.11.1 ,because my application is working fine for apache-cassandra-3.0.15. ? Kindly, revert ASAP. Thanks and Regards, Gaurav Kumar- Software Engineer
Re: Implicit Casts for Arithmetic Operators
Sounds good to me. On Fri, Nov 16, 2018 at 5:09 AM Benedict Elliott Smith wrote: > So, this thread somewhat petered out. > > There are still a number of unresolved issues, but to make progress I > wonder if it would first be helpful to have a vote on ensuring we are ANSI > SQL 92 compliant for our arithmetic? This seems like a sensible baseline, > since we will hopefully minimise surprise to operators this way. > > If people largely agree, I will call a vote, and we can pick up a couple > of more focused discussions afterwards on how we interpret the leeway it > gives. > > > > On 12 Oct 2018, at 18:10, Ariel Weisberg wrote: > > > > Hi, > > > > From reading the spec. Precision is always implementation defined. The > spec specifies scale in several cases, but never precision for any type or > operation (addition/subtraction, multiplication, division). > > > > So we don't implement anything remotely approaching precision and scale > in CQL when it comes to numbers I think? So we aren't going to follow the > spec for scale. We are already pretty far down that road so I would leave > it alone. > > > > I don't think the spec is asking for the most approximate type. It's > just saying the result is approximate, and the precision is implementation > defined. We could return either float or double. I think if one of the > operands is a double we should return a double because clearly the schema > thought a double was required to represent that number. I would also be in > favor of returning a double all the time so that people can expect a > consistent type from expressions involving approximate numbers. > > > > I am a big fan of widening for arithmetic expressions in a database to > avoid having to error on overflow. You can go to the trouble of only > widening the minimum amount, but I think it's simpler if we always widen to > bigint and double. This would be something the spec allows. > > > > Definitely if we can make overflow not occur we should and the spec > allows that. We should also not return different types for the same operand > types just to work around overflow if we detect we need more precision. > > > > Ariel > > On Fri, Oct 12, 2018, at 12:45 PM, Benedict Elliott Smith wrote: > >> If it’s in the SQL spec, I’m fairly convinced. Thanks for digging this > >> out (and Mike for getting some empirical examples). > >> > >> We still have to decide on the approximate data type to return; right > >> now, we have float+bigint=double, but float+int=float. I think this is > >> fairly inconsistent, and either the approximate type should always win, > >> or we should always upgrade to double for mixed operands. > >> > >> The quoted spec also suggests that decimal+float=float, and decimal > >> +double=double, whereas we currently have decimal+float=decimal, and > >> decimal+double=decimal > >> > >> If we’re going to go with an approximate operand implying an > approximate > >> result, I think we should do it consistently (and consistent with the > >> SQL92 spec), and have the type of the approximate operand always be the > >> return type. > >> > >> This would still leave a decision for float+double, though. The most > >> consistent behaviour with that stated above would be to always take the > >> most approximate type to return (i.e. float), but this would seem to me > >> to be fairly unexpected for the user. > >> > >> > >>> On 12 Oct 2018, at 17:23, Ariel Weisberg wrote: > >>> > >>> Hi, > >>> > >>> I agree with what's been said about expectations regarding expressions > involving floating point numbers. I think that if one of the inputs is > approximate then the result should be approximate. > >>> > >>> One thing we could look at for inspiration is the SQL spec. Not to > follow dogmatically necessarily. > >>> > >>> From the SQL 92 spec regarding assignment > http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt section 4.6: > >>> " > >>>Values of the data types NUMERIC, DECIMAL, INTEGER, SMALLINT, > >>>FLOAT, REAL, and DOUBLE PRECISION are numbers and are all > mutually > >>>comparable and mutually assignable. If an assignment would > result > >>>in a loss of the most significant digits, an exception condition > >>>is raised. If least significant digits are lost, implementation- > >>>defined rounding or truncating occurs with no exception > condition > >>>being raised. The rules for arithmetic are generally governed by > >>>Subclause 6.12, "". > >>> " > >>> > >>> Section 6.12 numeric value expressions: > >>> " > >>>1) If the data type of both operands of a dyadic arithmetic > opera- > >>> tor is exact numeric, then the data type of the result is > exact > >>> numeric, with precision and scale determined as follows: > >>> ... > >>>2) If the data type of either operand of a dyadic arithmetic op- > >>> erator is approximate numeric, then the data type of the re- > >>> sult is
Re: Implicit Casts for Arithmetic Operators
So, this thread somewhat petered out. There are still a number of unresolved issues, but to make progress I wonder if it would first be helpful to have a vote on ensuring we are ANSI SQL 92 compliant for our arithmetic? This seems like a sensible baseline, since we will hopefully minimise surprise to operators this way. If people largely agree, I will call a vote, and we can pick up a couple of more focused discussions afterwards on how we interpret the leeway it gives. > On 12 Oct 2018, at 18:10, Ariel Weisberg wrote: > > Hi, > > From reading the spec. Precision is always implementation defined. The spec > specifies scale in several cases, but never precision for any type or > operation (addition/subtraction, multiplication, division). > > So we don't implement anything remotely approaching precision and scale in > CQL when it comes to numbers I think? So we aren't going to follow the spec > for scale. We are already pretty far down that road so I would leave it > alone. > > I don't think the spec is asking for the most approximate type. It's just > saying the result is approximate, and the precision is implementation > defined. We could return either float or double. I think if one of the > operands is a double we should return a double because clearly the schema > thought a double was required to represent that number. I would also be in > favor of returning a double all the time so that people can expect a > consistent type from expressions involving approximate numbers. > > I am a big fan of widening for arithmetic expressions in a database to avoid > having to error on overflow. You can go to the trouble of only widening the > minimum amount, but I think it's simpler if we always widen to bigint and > double. This would be something the spec allows. > > Definitely if we can make overflow not occur we should and the spec allows > that. We should also not return different types for the same operand types > just to work around overflow if we detect we need more precision. > > Ariel > On Fri, Oct 12, 2018, at 12:45 PM, Benedict Elliott Smith wrote: >> If it’s in the SQL spec, I’m fairly convinced. Thanks for digging this >> out (and Mike for getting some empirical examples). >> >> We still have to decide on the approximate data type to return; right >> now, we have float+bigint=double, but float+int=float. I think this is >> fairly inconsistent, and either the approximate type should always win, >> or we should always upgrade to double for mixed operands. >> >> The quoted spec also suggests that decimal+float=float, and decimal >> +double=double, whereas we currently have decimal+float=decimal, and >> decimal+double=decimal >> >> If we’re going to go with an approximate operand implying an approximate >> result, I think we should do it consistently (and consistent with the >> SQL92 spec), and have the type of the approximate operand always be the >> return type. >> >> This would still leave a decision for float+double, though. The most >> consistent behaviour with that stated above would be to always take the >> most approximate type to return (i.e. float), but this would seem to me >> to be fairly unexpected for the user. >> >> >>> On 12 Oct 2018, at 17:23, Ariel Weisberg wrote: >>> >>> Hi, >>> >>> I agree with what's been said about expectations regarding expressions >>> involving floating point numbers. I think that if one of the inputs is >>> approximate then the result should be approximate. >>> >>> One thing we could look at for inspiration is the SQL spec. Not to follow >>> dogmatically necessarily. >>> >>> From the SQL 92 spec regarding assignment >>> http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt section 4.6: >>> " >>>Values of the data types NUMERIC, DECIMAL, INTEGER, SMALLINT, >>>FLOAT, REAL, and DOUBLE PRECISION are numbers and are all mutually >>>comparable and mutually assignable. If an assignment would result >>>in a loss of the most significant digits, an exception condition >>>is raised. If least significant digits are lost, implementation- >>>defined rounding or truncating occurs with no exception condition >>>being raised. The rules for arithmetic are generally governed by >>>Subclause 6.12, "". >>> " >>> >>> Section 6.12 numeric value expressions: >>> " >>>1) If the data type of both operands of a dyadic arithmetic opera- >>> tor is exact numeric, then the data type of the result is exact >>> numeric, with precision and scale determined as follows: >>> ... >>>2) If the data type of either operand of a dyadic arithmetic op- >>> erator is approximate numeric, then the data type of the re- >>> sult is approximate numeric. The precision of the result is >>> implementation-defined. >>> " >>> >>> And this makes sense to me. I think we should only return an exact result >>> if both of
Re: Cassandra 4.0 on Windows 10 crashing upon startup with Java 11
On 11/12/18 5:37 PM, Michael Shuler wrote: Issue with upstream links to: https://github.com/hyperic/sigar/issues/77 .. clip. Considering the Sigar has been unmaintained for years (and has large amount of unfixed bugs), should we consider removing it from the project? It's not used much, so finding suitable replacement for those few functions shouldn't be that big of a deal. - Micke - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
