Open JeromeChauveau opened 4 years ago
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.
Thanks a lot for your feedback, @doanduyhai
Thank you, I'm interested as well. Thank you @doanduyhai.
Updates?
The refactor is massive
Module achilles-model && achilles-common done
Next: achilles-core, the biggest challenge
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 ?
Datastax mapper is painful to use. If we can implement that somehow and make it easier to use, that would be best. :)
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
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.
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
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.
Ask Olivier Michalat on the driver mailing list
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.
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.
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:
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:
So my advise for people using Achilles and willing to migrate to 4.x branch are:
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.
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
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