@scylladb/python-driver-maint - if that's an acceptable path, I'll now proceed to remove code that assumed there might be more fields returning from those queries (especially DSE related stuff).

@scylladb/python-driver-maint - if that's an acceptable path, I'll now proceed to remove code that assumed there might be more fields returning from those queries (especially DSE related stuff).

Ah - I cannot remove those additional fields, as long as we do _SELECT_PEERS_V2 = "SELECT * FROM system.peers_v2" - should I fix this too?
If we don't need some unused items, such as dse_version, dse_workload, dse_workloads and others, more code can be dropped.

If we do keep this, I believe this PR is ready as is.

I am thinking that to make it future proof it would be better to have a logic that reads schema of the table and returns rows that exist there from which we can combine query that will contain all the columns we want.
It will fit perfectly into initiative to prepare all the statements that driver runs of it self.

@Lorak-mmk , WDYT ?

I am thinking that to make it future proof it would be better to have a logic that reads schema of the table and returns rows that exist there from which we can combine query that will contain all the columns we want. It will fit perfectly into initiative to prepare all the statements that driver runs of it self.

@Lorak-mmk , WDYT ?

How many times those tables change? It's not a bad idea to get into CI the current schema and every version compare to what we stored, but I would not add it to the driver. If we add something to core, for the driver sake, you'd assume there will be an issue for the driver side too.

In any case, orthogonal to this PR.

I am thinking that to make it future proof it would be better to have a logic that reads schema of the table and returns rows that exist there from which we can combine query that will contain all the columns we want. It will fit perfectly into initiative to prepare all the statements that driver runs of it self.
@Lorak-mmk , WDYT ?

How many times those tables change? It's not a bad idea to get into CI the current schema and every version compare to what we stored, but I would not add it to the driver. If we add something to core, for the driver sake, you'd assume there will be an issue for the driver side too.

In any case, orthogonal to this PR.

I don't think it is orthogonal, select * there solves exactly this problem, it allows one query handle all the cases.
If we make it specific we will see some cases when it is broken that we have not considered, old scylla, cassandra.

I am thinking that to make it future proof it would be better to have a logic that reads schema of the table and returns rows that exist there from which we can combine query that will contain all the columns we want. It will fit perfectly into initiative to prepare all the statements that driver runs of it self.
@Lorak-mmk , WDYT ?

How many times those tables change? It's not a bad idea to get into CI the current schema and every version compare to what we stored, but I would not add it to the driver. If we add something to core, for the driver sake, you'd assume there will be an issue for the driver side too.
In any case, orthogonal to this PR.

I don't think it is orthogonal, select * there solves exactly this problem, it allows one query handle all the cases. If we make it specific we will see some cases when it is broken that we have not considered, old scylla, cassandra.

OK, I don't know how to move forward here. It wasn't broken for years, the were minimal, if any, changes, none of them were critical to this part of the code (dse_workload? dse_workloads? What else was material that was added?). I thought such a benign change could get in easily.
I've looked at both the source code and a network traffic capture to see that I have all relevant items fetched, so I don't think we are missing anything. If we do miss it, it's easy to add it.

Let me know what the next step should be, or I'll just close the PR - both options are fine by me.

Imo we should ditch the DSE-related stuff, and SELECT * - let's select only what we need.
Reading schema and then building the query dynamically is possible, but is it really necessary? I don't think the driver needs anything weird that would require such approach.

Imo we should ditch the DSE-related stuff, and SELECT * - let's select only what we need. Reading schema and then building the query dynamically is possible, but is it really necessary? I don't think the driver needs anything weird that would require such approach.

This is the path I was going to pursue - remove some more dse stuff that now clearly is not fetched from system.local or system.peers.
Even if the driver uses system.peers_v2 - we don't really care about those fields (dse_workload, dse_workloads, as an example).

And removing the query to system.peers_v2 is also an option, but probably not in this PR.

And removing the query to system.peers_v2 is also an option, but probably not in this PR.

Is Scylla never going to support it?

And removing the query to system.peers_v2 is also an option, but probably not in this PR.

Is Scylla never going to support it?

Never say never. But even in that case, we wouldn't like to:

1. Perform 'SELECT *'
2. Try to pick up whatever we don't care about, such as 'dse_workload'

But again, this is not related to this PR. I'm not going to remove what peers_v2 might have, that is material (for example, some rpc port numbers, etc.)

@scylladb/python-driver-maint - do let me know how to proceed here (or drop the patch - either works). I have minor follow-ups to remove some useless .get() calls which do not fetch anything, but this is really minor.
Alternatively, we can remove peers_v2 and then there's even more code simplifications that can be done all over.

@scylladb/python-driver-maint - do let me know how to proceed here (or drop the patch - either works). I have minor follow-ups to remove some useless .get() calls which do not fetch anything, but this is really minor. Alternatively, we can remove peers_v2 and then there's even more code simplifications that can be done all over.

History wise it would be better to drop DSE part of the code and then merge this one.

@scylladb/python-driver-maint - do let me know how to proceed here (or drop the patch - either works). I have minor follow-ups to remove some useless .get() calls which do not fetch anything, but this is really minor. Alternatively, we can remove peers_v2 and then there's even more code simplifications that can be done all over.

History wise it would be better to drop DSE part of the code and then merge this one.

Should I then start with dropping PEERS_V2 stuff, then on top of it this item?

Can we avoid dropping PEERS_V2? It is not DSE-specific.

TBH, 100% proper way would be to evacuate all these queries to some class with API get all the peers.
Init that class when control connection is created depending on whether it is scylla or not use one or another.

TBH, 100% proper way would be to evacuate all these queries to some class with API get all the peers. Init that class when control connection is created depending on whether it is scylla or not use one or another.

Is it worth the effort, vs, this small contained patch? It is modeled after previous changes done (not fetch the tokens) nearby, and it's a very simple localized change.

TBH, 100% proper way would be to evacuate all these queries to some class with API get all the peers. Init that class when control connection is created depending on whether it is scylla or not use one or another.

Is it worth the effort, vs, this small contained patch? It is modeled after previous changes done (not fetch the tokens) nearby, and it's a very simple localized change.

Ok, I have checked all the execution paths where it is used, this PR is good.
Let's do DSE part separately, sync it is targeting only scylla tables we good to go.