SD-Cassandra is not considering user-defined types that are referenced by other user-defined types when dropping/recreating schemas. This results in an error and failure for the application to restart.
If SD-Cassandra is configured to drop/recreate a schema upon application restart, it is important that user-defined types (UDT) are dropped in an order that accounts for references to other UDTs. If not, then a drop type will fail, resulting in the application failing to start. When working in developer mode (which is when you'd typically drop/recreate schemas frequently), this renders Spring Boot DevTools useless, because you would need to manually delete the UDTs before manually restarting the application.
For example, suppose that you have defined two UDTs, "pizza" and "toppings", such that "pizza" references "toppings". It is important that the "pizza" UDT be dropped before the "toppings" UDT or else you'll get an error that looks like this:
InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot drop user type pizzaapp.topping as it is still used by table pizzaapp.pizza"
A look at https://github.com/spring-projects/spring-data-cassandra/blob/master/spring-data-cassandra/src/main/java/org/springframework/data/cassandra/core/CassandraPersistentEntitySchemaDropper.java#L83-L98 doesn't reveal anything obvious about the ordering of how UDTs are dropped. But neither does the dropTables() method above it--and I am assuming that dropTables() considers tables that reference each other when it is dropping them. (Or at least, I've not encountered any problems with tables like I'm having with UDTs.)
Side note: dropUserTypes() is quite similar in function to dropTables(), but they are written quite differently. One uses streams, while the other iterates over a collection. It would be nice if those two methods were more consistent in their coding (I favor the streams style).