Java driver 4.x compatibility

[JeromeChauveau]

Hello

Is a release with 4.x java driver planned? If so, do you have a target date in mind?

Thanks a lot for your feedback

Best regards

[doanduyhai]

Probably this summer when I'll have some bandwidth.

The 4.x driver has still some issues. The latest being perf regression due to upgraded Netty lib.

[JeromeChauveau]

Thanks a lot for your feedback, @doanduyhai

[bric3]

Thank you, I'm interested as well. Thank you @doanduyhai.

[hyperxpro]

Updates?

[doanduyhai]

The refactor is massive

Module achilles-model && achilles-common done

Next: achilles-core, the biggest challenge

[doanduyhai]

Ok ,some news. The refactoring is massive, the changes in the Java driver make it very hard to rely on existing classes of Achilles, especially the Query builder interface used internally by Achilles has completely changed. Upgrading to the new Java driver v4 is like rewriting Achilles.

Furthermore, there is a lot of interest from Datastax to improve their object mapper. The recent 4.9.0 release of the mapper module introduces Immutability support for entities.

So the question is: does it worth to continue developping Achilles instead of improving the new mapper module of Java driver v4 ?

Since version 4 Datastax has taken the same approach as Achilles, mainly compile-time code generation using annotation processor and Java Poet.

For me it does not make sense to continue pushing Achilles because it will create fragmentation in the community. Achilles did make sense in the past where no real alternative was available.

What do you think ?

[hyperxpro]

Datastax mapper is painful to use. If we can implement that somehow and make it easier to use, that would be best. :)

[doanduyhai]

Recently on the mailing list there is a guy asking for a special feature on the mapper, namely allowing to bind some subset of an entity property. Olivier Michalat seems to be eager to help

[hyperxpro]

I hate generating class code with Datastax Object Mapper. Do If we can introduce something like annotation-based or something which doesn't need generation, that would be good. No need for rewriting the entire Achilles just to support 4.x driver. We can fork and apply our patches into Datastax mapper and do our stuff on top of it.

[doanduyhai]

Class generation is the fundamental building block of Achilles to allow DSL style query builder:

select(). userName(). age() fromBaseTable(). where(). userId().eq(xxx)

without code generation it would be impossible to have type-safe DSL query like above. However I don't know how Datastax people manage their code generation

[hyperxpro]

Yeah, I was trying to say the same. Code generation, etc should be done behind the scenes. Because in-development, things change thousands of times, and generating code, again and again, is painful. That's why we need Achilles.

Though, we need to work on the Datastax code generation part to make it work with the new Achilles. I tried looking up on the Internet but found nothing. Datastax tutorials but couldn't understand anything. Maybe need to ask someone who worked with Datastax Object Mapper a lot.

[doanduyhai]

Ask Olivier Michalat on the driver mailing list

[hyperxpro]

Alright. I'll be dropping my question on the mailing list and once I have a good (if not the best) solution, I'll get back to you.

[bric3]

So the question is: does it worth to continue developping Achilles instead of improving the new mapper module of Java driver v4 ?

While I understand the burden of developing Achilles, if the direction is to use cassandra driver, then at least it might be good to have a somewhat intermediate release to ease the transition to the driver. Although this is certainly not a small task. Having an Achilles version that work cassandra driver 4 allows to make the migration incremental, letting developers migrate at their own is a major feature.

And eventually this may even attract cassandra driver 4.x that use the mapper to try Achilles.

[doanduyhai]

The more I investigate on the latest driver 4.x branch and the more I think it's a dead end.

Please read carefully some user feedbacks on the Cassandra Mailing List for driver 4.x branch:

https://www.mail-archive.com/user@cassandra.apache.org/msg61323.html

To summarise some concerns:

1. Big change in the policies implementation (retry, load-balancing ...) that are very opinionated
2. Huge change in public API, making frameworks or tools like Achilles very hard to migrate to this new version
3. Programmatic (type-safe) configuration, which does not bring much advantage for users, rather it makes their life harder
4. No more custom codec (a feature that Achilles doesn't need since it has its own codec system but some people using the pure driver does need)

All this put together makes the migration of existing applications from 3.x to 4.x branch rather complex (of course I'm talking about moderately complex real production apps, not toys apps for the purpose of demo)

But the most disturbing aspect of the 4.x branch is it donation (understand abandon : https://www.mail-archive.com/dev@cassandra.apache.org/msg15514.html ) to the Apache foundation by Datastax. Please read this reply by Alex Dutra in the Datastax Java Driver public mailing list:

https://groups.google.com/a/lists.datastax.com/g/java-driver-user/c/PxTnl40EB50/m/0LuXosYNBAAJ

Unfortunately the whole team is currently affected on other projects at DataStax and we won't have the bandwidth to fix this issue in a timely manner for you.

Given the new strategy of Datastax, given the new priority assigned to people working on the driver, and given the fact that Datastax is willing to donate the driver to the Apache foundation, I draw the following conclusion:

1. It is likely that the driver will no longer be maintained (or on a very small scale) by Datastax once the donation process is finished
2. The internal staff is already re-assigned to something else

So my advise for people using Achilles and willing to migrate to 4.x branch are:

1. Are you sure you want to migrate to a new 4.x driver that will likely be no longer maintained and much less matured than the 3.x version ?
2. The 3.x branch is still working pretty well for most of people and it is compatible with the future release of Cassandra 4.x
3. As for Achilles, I will not support 4.x branch of driver no matter what

[bric3]

OK, that situation is disappointing, I understand your decision. Thank you again for looking into it.

I don't know how long 3.x will be maintained, and other tools like Spring Boot already migrated to 4.x, so maybe the 4.x will only see less activity. Although if nowaday there's a solution, the future looks grim.

[doanduyhai]

NOTE: even if the driver donation to the Apache foundation is not officially accepted yet, Datastax already switches the driver team to other tasks.

In the CEP document, there is a clear question about long term driver maintenance after the donation. There is a list of people who are having actual expertise on some drivers:

Contributor	Relevant Driver Expertise
Olivier Michallat	Java
Alexandre Dutra	Java
Andrew Tolbert	Java, Node.js
Erik Merkle	Java
Greg Bestland	Java, Python
Tomasz Lelek	Java
Bret McGuire	Java
Adam Holmberg	Python, C++
Alan Boudreault	Python
Jim Witschey	Python
Jorge Bay Gondra	Node.js, C#
Joao Reis	C#
Michael Penick	C++, PHP
Michael Fero	C++, PHP
Sandeep Tamhankar	Ruby, C++, Java
Bulat Shakirzyanov	Ruby, PHP

However, there is no official commitment about these people to continue maintaining the drivers after the donation

It is worth noting the variety of employers of the above individuals; there is no guarantee that they are still involved on the project nor have a patron to fund their working on the project, and accepting the committer role is a personal decision made on a case-by-case basis.

For the short and mid term, sticking on Java driver 3.x branch is the most sensible and safe approach For the long term, if a clear commitment is made on the Java driver maintenance, start migrating to 4.x branch