I think we can wait 2 months to see how this advances before trying to workaround the issue. Moving to pure sql would complicate things for database support.
El mié, 8 ene 2025, 17:20, ricardo zanini fernandes <[email protected]> escribió: > Hi all! > > I also talked to Sanne, who said they might blog about it in the next few > days. I understand that it will be compelling for the Apache Legal team to > grasp the details and know that the process is ongoing and not as simple as > it sounds. > > On Wed, Jan 8, 2025 at 10:20 AM Alex Porcelli <[email protected]> wrote: > > > Thank you Kris for the update, and Francisco for the detailed > information. > > > > I'll reach out to IPMC and share the updated information available, > > and make sure that we are following this progress closely. > > > > Hopefully we won't need to make any drastic changes in the short term, > > as Sanne timeline seems reasonable. > > > > On Wed, Jan 8, 2025 at 10:03 AM Kris Verlaenen <[email protected]> wrote: > > > > > > I reached out to Sanne, the hibernate lead, and he replied that they > are > > > optimistic to finish the relicensing within two months, but can't > > guarantee > > > that timeframe won't slip. We should add some time for that version > being > > > merged into Quarkus (they have some branches for this already but still > > > could take some time) and it being available in a Quarkus LTS version. > > > > > > I think there's a preference to try and continue to leverage JPA in the > > > data index (to avoid having to write similar code ourselves). And to > see > > > if we can still support hibernate as a potential implementation. It > seems > > > that we should be able to do that in the mid-term future (due to the > > > relicensing). Do we need a different short-term strategy or is it an > > > option to wait a little longer? > > > > > > Thx, > > > Kris > > > > > > On Wed, Jan 8, 2025 at 11:13 AM Francisco Javier Tirado Sarti < > > > [email protected]> wrote: > > > > > > > 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] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
