Trying to save in cassandra with "SomeColumns"
The poblem is that I have a method from Spark to insert into Cassandra: childrenToInsertToParent.saveToCassandra("keyspace", "table", SomeColumns("a","b","c","d")) I have to put an sequence of String to say what columns I want to save. I would like to do it dinamically, to do that I have to save these names in an array, but it doesn't work with this paramter, any way to set an array to this method or similar? My idea is to get the name of the attributes from my case classes and put them directly, but I just can set the names in an array, list and so on.
RE: Roadmap for 4.0
Someone with an Apache email address has insisted this topic be moved to the dev list and not on a Jira so in an effort the help the group concentrate on making progress, I’ll post this topic there. Kenneth Brotman From: Kenneth Brotman [mailto:kenbrot...@yahoo.com] Sent: Friday, March 30, 2018 2:44 PM To: 'user@cassandra.apache.org' Subject: RE: Roadmap for 4.0 Jira 14357: https://issues.apache.org/jira/browse/CASSANDRA-14357 Just list any desired new major features for 4.0 that you want added. I will maintain a compiled list somewhere on this Jira as well. Don't worry about any steps beyond this. Don't make any judgements about or make any comments at all about what others add. No judgments at this point. This is a list of everyone's suggestions. Add your suggestions for new major features you desire be added for version 4.0 only. Trust me. This will get the ball rolling. Kenneth Brotman From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] Sent: Friday, March 30, 2018 2:33 PM To: user@cassandra.apache.org Subject: RE: Roadmap for 4.0 Does anyone have a simple list of new major features desired for 4.0? It should be a list of things desired regardless of judgements of any kind beyond that. Just start with that if you want to get anywhere. Kenneth Brotman From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] Sent: Friday, March 30, 2018 7:30 AM To: user@cassandra.apache.org Subject: RE: Roadmap for 4.0 Thanks Ben! I’m reading a book on Cassandra right now that says “The 4.0 release series is scheduled to begin in Fall 2016.” This is one of the group’s first big tests since things changed. Kenneth Brotman From: Ben Bromhead [mailto:b...@instaclustr.com] Sent: Friday, March 30, 2018 6:57 AM To: user@cassandra.apache.org Subject: Re: Roadmap for 4.0 After some further discussions with folks offline, I'd like to revive this discussion. As Kurt mentioned, to keep it simple I if we can simply build consensus around what is in for 4.0 and what is out. We can then start the process of working off a 4.0 branch towards betas and release candidates. Again as Kurt mentioned, assigning a timeline to it right now is difficult, but having a firm line in the sand around what features/patches are in, then limiting future 4.0 work to bug fixes will give folks a less nebulous target to work on. The other thing to mention is that once we have a 4.0 branch to work off, we at Instaclustr have a commitment to dogfooding the release candidates on our internal staging and internal production workloads before 4.0 becomes generally available. I know other folks have similar commitments and simply having a 4.0 branch with a clear list of things that are in or out will allow everyone to start testing and driving towards a quality release. The other thing is that there are already a large number of changes ready for 4.0, I would suggest not recommending tickets for 4.0 that have not yet been finished/have outstanding work unless you are the person working on it (or are offering to work on it instead) and can get it ready for review in a timely fashion. That way we can build a more realistic working target. For major breaking changes, there is always 5.0 or 4.1 or whatever we end up doing :) Cheers Ben On Thu, Feb 15, 2018 at 9:39 PM kurt greaveswrote: I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's possible Q3/Q4 alpha/beta is realistic, but definitely not a release. Well, this mostly depends on how much stuff to include in 4.0. Either way it's not terribly important. If people think 2019 is more realistic we can aim for that. As I said, it's just a rough timeframe to keep in mind. 3.10 was released in January 2017, and we've got around 180 changes for 4.0 so far, and let's be honest, 3.11 is still pretty young so it's going to be a significant effort to properly test and verify 4.0. Let's just stick to getting a list of changes for the moment. I probably shouldn't have mentioned timeframes, let's just keep in mind that we shouldn't have such a large set of changes for 4.0 that it takes us years to complete. All that said, what I really care about is building confidence in the release, which means an extended testing cycle. If all of those patches landed tomorrow, I'd still expect us to be months away from a release, because we need to bake the next major - there's too many changes to throw out an alpha/beta/rc and hope someone actually runs it. Yep. As I said, I'll follow up about testing after we sort out what we're actually going to include in 4.0. No point trying to come up with a testing plan for On 13 February 2018 at 04:25, Jeff Jirsa wrote: Advantages of cutting a release sooner than later: 1) The project needs to constantly progress forward. Releases are the most visible
RE: Roadmap for 4.0
Jira 14357: https://issues.apache.org/jira/browse/CASSANDRA-14357 Just list any desired new major features for 4.0 that you want added. I will maintain a compiled list somewhere on this Jira as well. Don't worry about any steps beyond this. Don't make any judgements about or make any comments at all about what others add. No judgments at this point. This is a list of everyone's suggestions. Add your suggestions for new major features you desire be added for version 4.0 only. Trust me. This will get the ball rolling. Kenneth Brotman From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] Sent: Friday, March 30, 2018 2:33 PM To: user@cassandra.apache.org Subject: RE: Roadmap for 4.0 Does anyone have a simple list of new major features desired for 4.0? It should be a list of things desired regardless of judgements of any kind beyond that. Just start with that if you want to get anywhere. Kenneth Brotman From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] Sent: Friday, March 30, 2018 7:30 AM To: user@cassandra.apache.org Subject: RE: Roadmap for 4.0 Thanks Ben! I’m reading a book on Cassandra right now that says “The 4.0 release series is scheduled to begin in Fall 2016.” This is one of the group’s first big tests since things changed. Kenneth Brotman From: Ben Bromhead [mailto:b...@instaclustr.com] Sent: Friday, March 30, 2018 6:57 AM To: user@cassandra.apache.org Subject: Re: Roadmap for 4.0 After some further discussions with folks offline, I'd like to revive this discussion. As Kurt mentioned, to keep it simple I if we can simply build consensus around what is in for 4.0 and what is out. We can then start the process of working off a 4.0 branch towards betas and release candidates. Again as Kurt mentioned, assigning a timeline to it right now is difficult, but having a firm line in the sand around what features/patches are in, then limiting future 4.0 work to bug fixes will give folks a less nebulous target to work on. The other thing to mention is that once we have a 4.0 branch to work off, we at Instaclustr have a commitment to dogfooding the release candidates on our internal staging and internal production workloads before 4.0 becomes generally available. I know other folks have similar commitments and simply having a 4.0 branch with a clear list of things that are in or out will allow everyone to start testing and driving towards a quality release. The other thing is that there are already a large number of changes ready for 4.0, I would suggest not recommending tickets for 4.0 that have not yet been finished/have outstanding work unless you are the person working on it (or are offering to work on it instead) and can get it ready for review in a timely fashion. That way we can build a more realistic working target. For major breaking changes, there is always 5.0 or 4.1 or whatever we end up doing :) Cheers Ben On Thu, Feb 15, 2018 at 9:39 PM kurt greaveswrote: I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's possible Q3/Q4 alpha/beta is realistic, but definitely not a release. Well, this mostly depends on how much stuff to include in 4.0. Either way it's not terribly important. If people think 2019 is more realistic we can aim for that. As I said, it's just a rough timeframe to keep in mind. 3.10 was released in January 2017, and we've got around 180 changes for 4.0 so far, and let's be honest, 3.11 is still pretty young so it's going to be a significant effort to properly test and verify 4.0. Let's just stick to getting a list of changes for the moment. I probably shouldn't have mentioned timeframes, let's just keep in mind that we shouldn't have such a large set of changes for 4.0 that it takes us years to complete. All that said, what I really care about is building confidence in the release, which means an extended testing cycle. If all of those patches landed tomorrow, I'd still expect us to be months away from a release, because we need to bake the next major - there's too many changes to throw out an alpha/beta/rc and hope someone actually runs it. Yep. As I said, I'll follow up about testing after we sort out what we're actually going to include in 4.0. No point trying to come up with a testing plan for On 13 February 2018 at 04:25, Jeff Jirsa wrote: Advantages of cutting a release sooner than later: 1) The project needs to constantly progress forward. Releases are the most visible part of that. 2) Having a huge changelog in a release increases the likelihood of bugs that take time to find. Advantages of a slower release: 1) We don't do major versions often, and when we do breaking changes (protocol, file format, etc), we should squeeze in as many as possible to avoid having to roll new majors 2) There are probably few people actually running 3.11
RE: Roadmap for 4.0
Does anyone have a simple list of new major features desired for 4.0? It should be a list of things desired regardless of judgements of any kind beyond that. Just start with that if you want to get anywhere. Kenneth Brotman From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] Sent: Friday, March 30, 2018 7:30 AM To: user@cassandra.apache.org Subject: RE: Roadmap for 4.0 Thanks Ben! I’m reading a book on Cassandra right now that says “The 4.0 release series is scheduled to begin in Fall 2016.” This is one of the group’s first big tests since things changed. Kenneth Brotman From: Ben Bromhead [mailto:b...@instaclustr.com] Sent: Friday, March 30, 2018 6:57 AM To: user@cassandra.apache.org Subject: Re: Roadmap for 4.0 After some further discussions with folks offline, I'd like to revive this discussion. As Kurt mentioned, to keep it simple I if we can simply build consensus around what is in for 4.0 and what is out. We can then start the process of working off a 4.0 branch towards betas and release candidates. Again as Kurt mentioned, assigning a timeline to it right now is difficult, but having a firm line in the sand around what features/patches are in, then limiting future 4.0 work to bug fixes will give folks a less nebulous target to work on. The other thing to mention is that once we have a 4.0 branch to work off, we at Instaclustr have a commitment to dogfooding the release candidates on our internal staging and internal production workloads before 4.0 becomes generally available. I know other folks have similar commitments and simply having a 4.0 branch with a clear list of things that are in or out will allow everyone to start testing and driving towards a quality release. The other thing is that there are already a large number of changes ready for 4.0, I would suggest not recommending tickets for 4.0 that have not yet been finished/have outstanding work unless you are the person working on it (or are offering to work on it instead) and can get it ready for review in a timely fashion. That way we can build a more realistic working target. For major breaking changes, there is always 5.0 or 4.1 or whatever we end up doing :) Cheers Ben On Thu, Feb 15, 2018 at 9:39 PM kurt greaveswrote: I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's possible Q3/Q4 alpha/beta is realistic, but definitely not a release. Well, this mostly depends on how much stuff to include in 4.0. Either way it's not terribly important. If people think 2019 is more realistic we can aim for that. As I said, it's just a rough timeframe to keep in mind. 3.10 was released in January 2017, and we've got around 180 changes for 4.0 so far, and let's be honest, 3.11 is still pretty young so it's going to be a significant effort to properly test and verify 4.0. Let's just stick to getting a list of changes for the moment. I probably shouldn't have mentioned timeframes, let's just keep in mind that we shouldn't have such a large set of changes for 4.0 that it takes us years to complete. All that said, what I really care about is building confidence in the release, which means an extended testing cycle. If all of those patches landed tomorrow, I'd still expect us to be months away from a release, because we need to bake the next major - there's too many changes to throw out an alpha/beta/rc and hope someone actually runs it. Yep. As I said, I'll follow up about testing after we sort out what we're actually going to include in 4.0. No point trying to come up with a testing plan for On 13 February 2018 at 04:25, Jeff Jirsa wrote: Advantages of cutting a release sooner than later: 1) The project needs to constantly progress forward. Releases are the most visible part of that. 2) Having a huge changelog in a release increases the likelihood of bugs that take time to find. Advantages of a slower release: 1) We don't do major versions often, and when we do breaking changes (protocol, file format, etc), we should squeeze in as many as possible to avoid having to roll new majors 2) There are probably few people actually running 3.11 at scale, so probably few people actually testing trunk. In terms of "big" changes I'd like to see land, the ones that come to mind are: https://issues.apache.org/jira/browse/CASSANDRA-9754 - "Birch" (changes file format) https://issues.apache.org/jira/browse/CASSANDRA-13442 - Transient Replicas (probably adds new replication strategy or similar) https://issues.apache.org/jira/browse/CASSANDRA-13628 - Rest of the internode netty stuff (no idea if this changes internode stuff, but I bet it's a lot easier if it lands on a major) https://issues.apache.org/jira/browse/CASSANDRA-7622 - Virtual Tables (selfish inclusion, probably doesn't need to be a major at all, and I wouldn't even lose sleep if it slips,
RE: Roadmap for 4.0
Thanks Ben! I’m reading a book on Cassandra right now that says “The 4.0 release series is scheduled to begin in Fall 2016.” This is one of the group’s first big tests since things changed. Kenneth Brotman From: Ben Bromhead [mailto:b...@instaclustr.com] Sent: Friday, March 30, 2018 6:57 AM To: user@cassandra.apache.org Subject: Re: Roadmap for 4.0 After some further discussions with folks offline, I'd like to revive this discussion. As Kurt mentioned, to keep it simple I if we can simply build consensus around what is in for 4.0 and what is out. We can then start the process of working off a 4.0 branch towards betas and release candidates. Again as Kurt mentioned, assigning a timeline to it right now is difficult, but having a firm line in the sand around what features/patches are in, then limiting future 4.0 work to bug fixes will give folks a less nebulous target to work on. The other thing to mention is that once we have a 4.0 branch to work off, we at Instaclustr have a commitment to dogfooding the release candidates on our internal staging and internal production workloads before 4.0 becomes generally available. I know other folks have similar commitments and simply having a 4.0 branch with a clear list of things that are in or out will allow everyone to start testing and driving towards a quality release. The other thing is that there are already a large number of changes ready for 4.0, I would suggest not recommending tickets for 4.0 that have not yet been finished/have outstanding work unless you are the person working on it (or are offering to work on it instead) and can get it ready for review in a timely fashion. That way we can build a more realistic working target. For major breaking changes, there is always 5.0 or 4.1 or whatever we end up doing :) Cheers Ben On Thu, Feb 15, 2018 at 9:39 PM kurt greaveswrote: I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's possible Q3/Q4 alpha/beta is realistic, but definitely not a release. Well, this mostly depends on how much stuff to include in 4.0. Either way it's not terribly important. If people think 2019 is more realistic we can aim for that. As I said, it's just a rough timeframe to keep in mind. 3.10 was released in January 2017, and we've got around 180 changes for 4.0 so far, and let's be honest, 3.11 is still pretty young so it's going to be a significant effort to properly test and verify 4.0. Let's just stick to getting a list of changes for the moment. I probably shouldn't have mentioned timeframes, let's just keep in mind that we shouldn't have such a large set of changes for 4.0 that it takes us years to complete. All that said, what I really care about is building confidence in the release, which means an extended testing cycle. If all of those patches landed tomorrow, I'd still expect us to be months away from a release, because we need to bake the next major - there's too many changes to throw out an alpha/beta/rc and hope someone actually runs it. Yep. As I said, I'll follow up about testing after we sort out what we're actually going to include in 4.0. No point trying to come up with a testing plan for On 13 February 2018 at 04:25, Jeff Jirsa wrote: Advantages of cutting a release sooner than later: 1) The project needs to constantly progress forward. Releases are the most visible part of that. 2) Having a huge changelog in a release increases the likelihood of bugs that take time to find. Advantages of a slower release: 1) We don't do major versions often, and when we do breaking changes (protocol, file format, etc), we should squeeze in as many as possible to avoid having to roll new majors 2) There are probably few people actually running 3.11 at scale, so probably few people actually testing trunk. In terms of "big" changes I'd like to see land, the ones that come to mind are: https://issues.apache.org/jira/browse/CASSANDRA-9754 - "Birch" (changes file format) https://issues.apache.org/jira/browse/CASSANDRA-13442 - Transient Replicas (probably adds new replication strategy or similar) https://issues.apache.org/jira/browse/CASSANDRA-13628 - Rest of the internode netty stuff (no idea if this changes internode stuff, but I bet it's a lot easier if it lands on a major) https://issues.apache.org/jira/browse/CASSANDRA-7622 - Virtual Tables (selfish inclusion, probably doesn't need to be a major at all, and I wouldn't even lose sleep if it slips, but I'd like to see it land) Stuff I'm ok with slipping to 4.X or 5.0, but probably needs to land on a major because we'll change something big (like gossip, or the way schema is passed, etc): https://issues.apache.org/jira/browse/CASSANDRA-9667 - Strongly consistent membership https://issues.apache.org/jira/browse/CASSANDRA-10699 - Strongly consistent schema All that said,
Re: Roadmap for 4.0
After some further discussions with folks offline, I'd like to revive this discussion. As Kurt mentioned, to keep it simple I if we can simply build consensus around what is in for 4.0 and what is out. We can then start the process of working off a 4.0 branch towards betas and release candidates. Again as Kurt mentioned, assigning a timeline to it right now is difficult, but having a firm line in the sand around what features/patches are in, then limiting future 4.0 work to bug fixes will give folks a less nebulous target to work on. The other thing to mention is that once we have a 4.0 branch to work off, we at Instaclustr have a commitment to dogfooding the release candidates on our internal staging and internal production workloads before 4.0 becomes generally available. I know other folks have similar commitments and simply having a 4.0 branch with a clear list of things that are in or out will allow everyone to start testing and driving towards a quality release. The other thing is that there are already a large number of changes ready for 4.0, I would suggest not recommending tickets for 4.0 that have not yet been finished/have outstanding work unless you are the person working on it (or are offering to work on it instead) and can get it ready for review in a timely fashion. That way we can build a more realistic working target. For major breaking changes, there is always 5.0 or 4.1 or whatever we end up doing :) Cheers Ben On Thu, Feb 15, 2018 at 9:39 PM kurt greaveswrote: > I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's >> possible Q3/Q4 alpha/beta is realistic, but definitely not a release. > > Well, this mostly depends on how much stuff to include in 4.0. Either way > it's not terribly important. If people think 2019 is more realistic we can > aim for that. As I said, it's just a rough timeframe to keep in mind. > > 3.10 was released in January 2017, and we've got around 180 changes for > 4.0 so far, and let's be honest, 3.11 is still pretty young so it's going > to be a significant effort to properly test and verify 4.0. > Let's just stick to getting a list of changes for the moment. I probably > shouldn't have mentioned timeframes, let's just keep in mind that we > shouldn't have such a large set of changes for 4.0 that it takes us years > to complete. > > All that said, what I really care about is building confidence in the >> release, which means an extended testing cycle. If all of those patches >> landed tomorrow, I'd still expect us to be months away from a release, >> because we need to bake the next major - there's too many changes to throw >> out an alpha/beta/rc and hope someone actually runs it. > > Yep. As I said, I'll follow up about testing after we sort out what we're > actually going to include in 4.0. No point trying to come up with a testing > plan for > > On 13 February 2018 at 04:25, Jeff Jirsa wrote: > >> >> Advantages of cutting a release sooner than later: >> 1) The project needs to constantly progress forward. Releases are the >> most visible part of that. >> 2) Having a huge changelog in a release increases the likelihood of bugs >> that take time to find. >> >> Advantages of a slower release: >> 1) We don't do major versions often, and when we do breaking changes >> (protocol, file format, etc), we should squeeze in as many as possible to >> avoid having to roll new majors >> 2) There are probably few people actually running 3.11 at scale, so >> probably few people actually testing trunk. >> >> In terms of "big" changes I'd like to see land, the ones that come to >> mind are: >> >> https://issues.apache.org/jira/browse/CASSANDRA-9754 - "Birch" (changes >> file format) >> https://issues.apache.org/jira/browse/CASSANDRA-13442 - Transient >> Replicas (probably adds new replication strategy or similar) >> https://issues.apache.org/jira/browse/CASSANDRA-13628 - Rest of the >> internode netty stuff (no idea if this changes internode stuff, but I bet >> it's a lot easier if it lands on a major) >> https://issues.apache.org/jira/browse/CASSANDRA-7622 - Virtual Tables >> (selfish inclusion, probably doesn't need to be a major at all, and I >> wouldn't even lose sleep if it slips, but I'd like to see it land) >> >> Stuff I'm ok with slipping to 4.X or 5.0, but probably needs to land on a >> major because we'll change something big (like gossip, or the way schema is >> passed, etc): >> >> https://issues.apache.org/jira/browse/CASSANDRA-9667 - Strongly >> consistent membership >> https://issues.apache.org/jira/browse/CASSANDRA-10699 - Strongly >> consistent schema >> >> All that said, what I really care about is building confidence in the >> release, which means an extended testing cycle. If all of those patches >> landed tomorrow, I'd still expect us to be months away from a release, >> because we need to bake the next major - there's too many changes to throw >> out an alpha/beta/rc and hope someone