Thanks for having a look. The design requires a bit more thought and not everything should be a String or Exception. Design-wise, we should decouple validation from any factory beans for a clearer separation of concerns. Later on, once the validation part is fine, we can consider how to integrate validation into application startup.

For type resolution, I suggest you have a look at DefaultColumnTypeResolver and SchemaFactory, how data types are derived from properties.

Also, validation findings should be part of a model (ColumnNotFound, TableNotFound) along with references to the underlying CQL item/persistent property/persistent entity.

Let me know whether that helps.

@mp911de I have introduced a couple of changes in accordance to what you've said:

1. CassandraSchemaValidator now accepts CqlSession directly instead of CqlSessionFactoryBean
2. CassandraSchemaValidator now also accepts CassandraConverter instead of CassandraMappingContext. This allwos getting CassandraMappingContext from CassandraConverter and also the creation of DefaultColumnTypeResolver instance using CassandraConverter`

But I do not fully understand wht you mean here:

Also, validation findings should be part of a model (ColumnNotFound, TableNotFound) along with references to the underlying CQL item/persistent property/persistent entity.

Can you please give me a glue what is your vision here? You want CassandraSchemaValidationProfile to accept not String objects as validation error messages but have an abstraction over a message, such as ColumnNotFound and TableNotFound and so on, am I correct?

I have rebased this PR. Any chance to review it? @mp911de

Currently, this ticket (and several other ones) is on pause because we're limited in bandwidth. We currently can only fix smaller bugs and I don't know when we will have more time for proper enhancements.