using Statement instead of Select

[tigran10]

It was not possible to call cassandraTemplate.select() method after creating a Statement via QueryBuilder, as it takes only Select as an argument

//example
val select: Statement = QueryBuilder.select().all().from(tableName).setFetchSize(maxResults)

Statement appears as a Base Class for Select and others, I havent look much why cassandraTemplate was tailored specifically for Select, but the tests are passing with Statement so hopefully this change make sense.

[matthewadams]

Hi, can you please add an issue for this at https://jira.spring.io/browse/DATACASS?

[matthewadams]

The current API design attempts to ensure that a Select is given to a select method, an Insert is given to an insert method, and so on. It is true that Statement is the base class for these, and is the only statement type that can be created from a string. Have a look at https://datastax-oss.atlassian.net/browse/JAVA-448, where I discuss a related (or even the same) issue. As of now, this appears to be more of a limitation of the underlying Java driver than of SDC. If we overloaded select(..), insert(..), etc, to take a Statement, there wouldn't be much type safety; you could pass an Insert instance to a select(Statement, ..) method, and so on. Ideally, if you could create a Select, Insert, etc, from a string, you'd be good to go. I'm going to close this PR for now, pending the resolution of JAVA-448.

[tigran10]

Hi, thanks for the reply, so as you said I have created an issue at https://jira.spring.io/browse/DATACASS-181

and yes, agree there wouldnt be compile time type safety at all if we change the whole slice to take Statement.

One thing is not really clear from the driver is why setFetchSize(maxResults) is returning Statement but not Select, as up to that point Builder is returning Select and i cant see how setFetchSize can make things more generic and why to return base class.