New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementing keyspace qualification for particular entities #1400
base: main
Are you sure you want to change the base?
Conversation
Have you seen #179? Introducing keyspace to tables raises another set of questions that we tried to address with the previous pull request. For simplicity, let's decouple all polishing within this pull request into a separate one, as the cleanups are almost a no-brainer to merge. |
@mp911de No, not yet. But I have checked it now. Regardign this commet, I think it is the good idea. So we'll just introduce new P.S: Also I think we should not expose I can introduce new overloaded methods to an API of CassandraTemplate to accept this new Any other key components for me to consider?) By the way, I have separated the polishing commits already. You want me to create a separate PR for this?) |
Applying a keyspace to a table sounds straight-forward, but there are a few things to consider:
IMO, the keyspace isn't something that is detached from the actual identifier but it rather enriches it. A much more appropriate way to think about this is thinking whether the identifier is qualified or unqualified and having an extension to |
I filed https://datastax-oss.atlassian.net/browse/JAVA-3088 asking for constructor rules relaxation. |
Yeah, I agree with you. |
Hello @mp911de @schauder !
I have implemented #921 feature. I have assumed the following behavoir:
@Table
annotation. If it is specified, then for each query we just pass toQueryBuilder
keyspace specified by user. The goal again is not to mutate CqlSession and avoid creating CqlSession for each keyspace.I hope it makes sence to you as well. Any suggestions/improvements will be highly appretiated. Thanks!