pekko-projection-slick scala 3 support?

[pjfanning]

pekko-projection-slick depends on pekko-persistence-jdbc and Slick

To pick up the Scala 3 support in pekko-persistence-jdbc, we would need pekko-persistence-jdbc 1.1.x (when it is released).

I think our general preference would be not to have to change to using pekko-persistence-jdbc 1.1.x but in this case, we might want to make an exception.

• In theory, we could only depend on pekko-persistence-jdbc 1.1.x for pekko-projection-slick_3 (i.e the Scala 3 jar and not the Scala 2.x jars)
• we could just not bother supporting Scala 3 for pekko-projection-slick because this module is deprecated - see https://pekko.apache.org/docs/pekko-projection/current/slick.html - we have pekko-projection-jdbc and this supports Scala 3
• we could just upgrade to pekko-persistence-jdbc 1.1.x as an exception

[pjfanning]

wdyt @mdedetrich @raboof @He-Pin @Roiocam @samueleresca @gmethvin @nvollmar ?

[PerWiklander]

We have not switched to Pekko yet, but over here in the upside down we have the exact same problem with the Akka counter parts and for our project it is a great help that akka-projection-slick gets Scala 3 support. This pushes our whole project over to Scala 3 and we can check that box before trying to get rid of Slick.

[pjfanning]

@PerWiklander is there a reason not to switch to projection-jdbc? Both Akka and Pekko regard projection-slick as deprecated in favour of projection-jdbc.

[PerWiklander]

We have a large slick-based db layer. We see a pro in handling writing to view tables and the projection book keeping in the same slick session / transaction. Our way forwards is to move our view storage to Neo4j, so we will leave the whole jdbc/slick/sql world behind. In this regard it is easier to keep our slick based projections for now.

[mdedetrich]

@PerWiklander is there a reason not to switch to projection-jdbc? Both Akka and Pekko regard projection-slick as deprecated in favour of projection-jdbc.

I wouldn't look too much into the deprecation from Akka's side, which we "inherited". My impression is that this deprecation wasn't technical in nature but rather a reduction of scope which due to how much Akka was maintaining was becoming a problem (after all this was one of the reasons behind the change to the BSL license). In other words they deprecated projection-slick for the same reasons they gave Play to the community, too much to handle for them.

For this reason I would actually be for undeprecating projection-slick assuming we have community support, but we can only do that if we see enough community takeup which isn't possible right now because as is evidenced people can't even use projection-slick due to how outdated the Slick version is and/or missing Scala 3 support. Classic chicken and egg problem that persistence-jdbc also experiences, which means we need to release with latest version of Slick before making any such judgement.

I think our general preference would be not to have to change to using pekko-persistence-jdbc 1.1.x but in this case, we might want to make an exception.

Actually this is likely going to be the general case of Pekko modules that are not the core ones (i.e. pekko core/http/grpc etc etc). By definition of us making 1.0.x series a copy of the state of Akka before the fork that is frozen aside from critical bug/security fixes, this situation of having some module 1.1.x (projection-slick) depending on another modules 1.1.x (persistence-jdbc) was always going to happen. This is also the same reason why I was against releasing the initial Pekko fork as 1.0.x but rather 0.9.x because this EarlySemVer versioning scheme makes this very clear, where as now we have a situation where initial impressions imply that various modules in Pekko are fully SemVer with others when clearly this can't be the case.

In summary what I think makes most sense is to release pekko-persistence-jdbc 1.1.0-M1 which is already being discussed and then have pekko-projection-slick 1.1.x depend on it which means that we will start a 1.1.x series of projection. Like pekko-persistence-jdbc it also makes sense to release a M1 of projection 1.1.x series just so we can gauge community sentiment in general.

What is becoming increasingly clear is that we are downplaying the interest of these modules, largely because people can't even use them due to how outdated certain dependencies are (ergo Slick) and/or misisng Scala 3 support

[pjfanning]

#167 merged