You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kie.apache.org by Francisco Javier Tirado Sarti <ft...@redhat.com> on 2025/01/07 11:55:24 UTC
[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.
Re: [DISCUSS] Hibernate usage
Posted by Enrique Gonzalez Martinez <el...@gmail.com>.
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 <ri...@gmail.com>
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 <al...@porcelli.me> 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 <kr...@apache.org> 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 <
> > > ftirados@redhat.com> 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 <po...@apache.org>
> > 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
> <jporter@ibm.com.invalid
> > >
> > > > > 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 <ft...@redhat.com>
> > > > > > Date: Tuesday, January 7, 2025 at 04:55
> > > > > > To: dev@kie.apache.org <de...@kie.apache.org>
> > > > > > 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: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
Re: [DISCUSS] Hibernate usage
Posted by ricardo zanini fernandes <ri...@gmail.com>.
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 <al...@porcelli.me> 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 <kr...@apache.org> 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 <
> > ftirados@redhat.com> 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 <po...@apache.org>
> 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 <jporter@ibm.com.invalid
> >
> > > > 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 <ft...@redhat.com>
> > > > > Date: Tuesday, January 7, 2025 at 04:55
> > > > > To: dev@kie.apache.org <de...@kie.apache.org>
> > > > > 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: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [DISCUSS] Hibernate usage
Posted by Alex Porcelli <al...@porcelli.me>.
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 <kr...@apache.org> 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 <
> ftirados@redhat.com> 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 <po...@apache.org> 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 <jp...@ibm.com.invalid>
> > > 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 <ft...@redhat.com>
> > > > Date: Tuesday, January 7, 2025 at 04:55
> > > > To: dev@kie.apache.org <de...@kie.apache.org>
> > > > 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: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [DISCUSS] Hibernate usage
Posted by Kris Verlaenen <kr...@apache.org>.
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 <
ftirados@redhat.com> 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 <po...@apache.org> 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 <jp...@ibm.com.invalid>
> > 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 <ft...@redhat.com>
> > > Date: Tuesday, January 7, 2025 at 04:55
> > > To: dev@kie.apache.org <de...@kie.apache.org>
> > > 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: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
Re: [DISCUSS] Hibernate usage
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
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 <po...@apache.org> 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 <jp...@ibm.com.invalid>
> 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 <ft...@redhat.com>
> > Date: Tuesday, January 7, 2025 at 04:55
> > To: dev@kie.apache.org <de...@kie.apache.org>
> > 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: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [DISCUSS] Hibernate usage
Posted by Alex Porcelli <po...@apache.org>.
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 <jp...@ibm.com.invalid> 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 <ft...@redhat.com>
> Date: Tuesday, January 7, 2025 at 04:55
> To: dev@kie.apache.org <de...@kie.apache.org>
> 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: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [DISCUSS] Hibernate usage
Posted by Jason Porter <jp...@ibm.com.INVALID>.
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 <ft...@redhat.com>
Date: Tuesday, January 7, 2025 at 04:55
To: dev@kie.apache.org <de...@kie.apache.org>
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.