Hi Alex, Reverting back to JDBC, which I actually suggested in the past <https://github.com/apache/incubator-kie-kogito-apps/issues/2009> (note my unfounded optimism about the licensing issue when closing the proposal ;)), is not a good technical idea for data-index and data-audit. In fact, the data-index use case (which is the one I'm more familiar with), which consists of a lot of random updates over a relatively small relational model, is one where JPA cache and automatic generation of SQL update statements really excels. Doing the same using JDBC, if we want to achieve the same performance, will be a really challenging exercise, because we will need to replicate the Hibernate logic to execute just the sql statements that are really needed because of that random change in the model. This is pretty tricky and is a work that is currently done automatically by JPA. Also, since the SQL statements slightly diverge between DBs (note that in runtimes, where the relational model is trivial, just a big table, and not queries are performed, this is not an issue, but it certainly will be for data-index, where the relational model is not trivial and queries are random) , we will actually need to redesign the whole stack of classes to ensure we can easily change statements between different dbs. Current class hierarchy does not easily allow that. For example, to use custom functions to enable querying Process.variables (which is a jsonb column in postgres and hence it can be queries using custom postgresql operators) I had to use a Quarkus trick (annotating one bean with @DefaultBean in common module and override it in postgres module). This smells fishy and if we are planning to control SQL per db (which, again, we need if we do not use JPA), we will need a different class hierarchy. In practice, it means to redevelop almost 30% of the data-index code and execute all the performance testing again. Therefore, unless we are 100% certain that Hibernate is not going to be ASLv2 compatible in one year, I will wait.
On Wed, Jan 8, 2025 at 1:00 AM Alex Porcelli <[email protected]> wrote: > As Jason has pointed out, the IPMC has already stated their position > regarding LGPL, and the rules are clear. I wanted to share my thoughts > on the possible paths forward: > > - Use OpenJPA: While this would address the licensing issue, it > introduces uncertainty around Quarkus deployment because Hibernate is > the only officially supported JPA provider in Quarkus. > > - Continue with Hibernate: Even though Hibernate might eventually > become ASLv2-compatible, it could be a long time before that version > is integrated into Quarkus and is considered production-ready. > > Given these points, another option might be reverting to plain JDBC. > Although this involves some extra initial work, it should be fully > supported by both Quarkus and SpringBoot, which could remove a > significant blocker with IPMC and help us move toward graduation. > > - > Alex > > On Tue, Jan 7, 2025 at 12:10 PM Jason Porter <[email protected]> > wrote: > > > > Until they actually change the license over to ASLv2, I seriously doubt > they’ll let us continue to ship with it. > > > > If we’re not using any of the hibernate specific APIs, I see very little > reason for us not to use OpenJPA for the dependencies, then allow users to > decide which JPA implementation they want to use. I’m sure we’ll need to do > a fair amount of testing though to make sure this doesn’t break things. > > > > -- > > Jason Porter > > Software Engineer > > He/Him/His > > > > IBM > > > > > > From: Francisco Javier Tirado Sarti <[email protected]> > > Date: Tuesday, January 7, 2025 at 04:55 > > To: [email protected] <[email protected]> > > Subject: [EXTERNAL] [DISCUSS] Hibernate usage > > Hi all, > > I feel the discussion we are having here > > https://github.com/apache/incubator-kie-issues/issues/1685 , actually > > belongs to that list. > > > > On summary, we narrow the issue to two choices: > > > > 1) Replace Hibernate with OpenJPA, as was done, kind of prematurely in my > > opinion (because this should be a broad KIE choice, not per subcomponent > > one) , in Drools repo. > > 2) Raise a legal issue to Apache so we can distribute Hibernate (based on > > the fact that eventually the Hibernate license will be Apache compliant) > > > > I'm fine with 1), but I feel we should also vote on that one. > > > > Kind regards and happy new year. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
