Due to how Spring Data binding works, you have to write queries
explicitly to use the "...FROM keyspace.table ..." in either the
template-method classes (CqlTemplate, etc) or via @Query annontations
to avoid the 'use keyspace' overhead. For example, a Repository
implementation for a User class (do this all by hand, do not use
CassandraRepository per Patrick's point of it being a traveling
carnival of cassandra anti-patterns) would look something like:

@Query("select id, email, name from myusers.user where id = ?0")
User findById(UUID id);

Another important note - only the template method classes that work
*directly* with prepared statements use them. In other words: *nothing
else in the API uses prepared statements.* And this is a massive
performance hit in statement parsing alone. There are open issues for
this in the SD jira:
https://jira.spring.io/browse/DATACASS-578
https://jira.spring.io/browse/DATACASS-510

If you stick to the cqlTemplate methods for working with
PreparedStatements and ResultSet extractors, etc, because you want
Spring to manage all the configuration, that's totally legit and it
will work well.

In general, this will be an good API one day as some of the Fluent
stuff for working with paged results sets is particularly excellent
and well crafted around modern Java paradigms (outside of not using
PreparedStatement unfortunately).

On Sun, Jul 22, 2018 at 1:15 PM, Goutham reddy
<goutham.chiru...@gmail.com> wrote:
> Hi,
> Consider overriding default java driver provided by spring boot if you are
> using Datastax clusters with with any of the 3.X Datastax driver. I agree to
> Patrick, always have one key space specified to one application in that way
> you achieve domain driven applications and cause less overhead avoiding
> switching between key spaces.
>
> Cheers,
> Goutham
>
> On Fri, Jul 20, 2018 at 10:10 AM Patrick McFadin <pmcfa...@gmail.com> wrote:
>>
>> Vitaliy,
>>
>> The DataStax Java driver is very actively maintained by a good size team
>> and a lot of great community contributors. It's version 3.x compatible and
>> even has some 4.x features starting to creep in. Support for virtual tables
>> (https://issues.apache.org/jira/browse/CASSANDRA-7622)  was just merged as
>> an example. Even the largest DataStax customers have a mix of enterprise +
>> OSS and we want to support them either way. Giving developers the most
>> consistent experience is part of that goal.
>>
>> As for spring-data-cassandra, it does pull the latest driver as a part of
>> its own build, so you will already have it in your classpath. Spring adds
>> some auto-magic that you should be aware. The part you mentioned about the
>> schema management, is one to be careful with using. If you use it in dev,
>> it's not a huge problem. If it gets out to prod, you could potentially have
>> A LOT of concurrent schema changes happening which can lead to bad things.
>> Also, some of the spring API features such as findAll() can expose typical
>> c* anti-patterns such as "allow filtering" Just be aware of what feature
>> does what. And finally, another potential production problem is that if you
>> use a lot of keyspaces, Spring will instantiate a new Driver Session object
>> per keyspace which can lead to a lot of redundant connection to the
>> database. From the driver, a better way is to specify a keyspace per query.
>>
>> As you are using spring-data-cassandra, please share your experiences if
>> you can. There are a lot of developers that would benefit from some
>> real-world stories.
>>
>> Patrick
>>
>>
>> On Fri, Jul 20, 2018 at 4:54 AM Vitaliy Semochkin <vitaliy...@gmail.com>
>> wrote:
>>>
>>> Thank you very much Duy Hai Doan!
>>> I have relatively simple demands and since spring using datastax
>>> driver I can always get back to it,
>>> though  I would prefer to use spring in order to do bootstrapping and
>>> resource management for me.
>>> On Fri, Jul 20, 2018 at 4:51 PM DuyHai Doan <doanduy...@gmail.com> wrote:
>>> >
>>> > Spring data cassandra is so so ... It has less features (at last at the
>>> > time I looked at it) than the default Java driver
>>> >
>>> > For driver, right now most of people are using Datastax's ones
>>> >
>>> > On Fri, Jul 20, 2018 at 3:36 PM, Vitaliy Semochkin
>>> > <vitaliy...@gmail.com> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> Which driver to use with cassandra 3
>>> >>
>>> >> the one that is provided by datastax, netflix or something else.
>>> >>
>>> >> Spring uses driver from datastax, though is it a reliable solution for
>>> >> a long term project, having in mind that datastax and cassandra
>>> >> parted?
>>> >>
>>> >> Regards,
>>> >> Vitaliy
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
>>> >> For additional commands, e-mail: user-h...@cassandra.apache.org
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: user-h...@cassandra.apache.org
>>>
> --
> Regards
> Goutham Reddy

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
For additional commands, e-mail: user-h...@cassandra.apache.org

Reply via email to