Hi Enrique, The original oracle module was a modified copy pasted version of the postgres one Later on, we created a common jpa module and two different modules that depend on that one, oracle and postgres, so we avoid the code duplication. The oracle and postges module differs on the handling of a json column (which also implies a change in schema) in postgres, the column is native jsonb in oracle, the column is a blob So, currently the oracle module we are proposing to delete contains: 1) The same test that are performed on posgres, but performed on oracle (thats why the driver is needed) 2) The json converter for blob, which is jdbc generic (meaning that it can be moved to a different module, and thats what we should do if we proceed with the removal) plust the orm.xml which activates the converter) 3) The application.properties that tell quarkus we are using oracle, so when the module is added as dependency to the pom using it, quarkus automatically use oracle. 4) The db schema for oracle
My proposal consistent on fully disabling 1) so the driver is no longer needed (avoiding any legal issue), but the module can still be added to a pom (plus the oracle quarkus dependency) so people in the community can still integrate data-index with oracle. PS: About compulsory, I think our intepreation is too strict, but thats a different discussion, it is a grey area, not black-white On Wed, Jan 31, 2024 at 1:20 PM Enrique Gonzalez Martinez < [email protected]> wrote: > Hi Francisco: > > Answer inline: > > El mié, 31 ene 2024 a las 11:38, Francisco Javier Tirado Sarti > (<[email protected]>) escribió: > > > > Hi Brian > > If the code was not functional, I would agree. But the code is fully > > functional and we are planning to remove it because of a controversial > > potential legal issue that, even with the more restricted view on that, > > only affects a dependency and its associated test. > > It is not "potential", it is a compulsory requirement. We need to > comply. This is a ruling above our project and for every apache > project. > > > That's why my PR is removing the driver and disable the test that fails > > when the driver is removed, but the code, which is essentially using > jdbc, > > not specific oracle stuff, is still being compiled and can be used by > > projects that include our code plus the driver. > > I don't want to get to much into detail but if we have a test for jdbc > and needs to be disabled because it requires oracle driver it means it > is not generic enough therefore it can be > enabled probably unless it is really tied to the vendor implementation > (no good). > > While my first reaction was proposing to disable as well, after the > Alex PR try, IMO there was not much sense to keep them because it is > not abstract enough. This problem is signaling that > our implementation is not good enough and requires some tweaks or the > tests are not properly done (from the generic point of view). So > either we change the tests or we remove the tweaks in the > implementation. > > > Also, I do not understand how you conclude that adding community Oracle > > support was a mistake? > > From my perspective, it is a mistake because: > 1. we need to comply with legal requirements. > 2. the design is flawed because bad test or persistence tier is > leaking abstractions > > Honestly at this point of the conversation I don't see sensible to > disable the test as this won't be part of the CI and therefore can be > broken at anytime and the alternative solution (better IMO) is to > improve the test and create a certification matrix where the driver > can be added. Keeping in mind that we are using jdbc it should not be > difficult. > > My 2c. > > > > > On Tue, Jan 30, 2024 at 10:40 PM Brian Proffitt <[email protected]> wrote: > > > > > Yeah, so, catching up on this, and I have to say, I don't understand > any > > > arguments to leave non-functional code that may not be in compliance > > > behind. Any code that jeopardizes compliance needs to be removed, and > > > workarounds created. > > > > > > If there is a genuine concern that somehow, some way, this code might > be > > > used later, than that's what version control is for: go back to an > older > > > version and pick up the code from there. > > > > > > The other mentors may have different solutions, but if you can scrape > out > > > the driver (binaries and code) and the functionality won't break, then > just > > > do it. > > > > > > On 2024/01/29 16:14:10 ricardo zanini fernandes wrote: > > > > I'd -1 to remove functional code added by a community member. This > would > > > > pass the wrong message. > > > > > > Sorry, it does suck, but sometimes people make honest mistakes and they > > > might need correction. It's not a personal slight, especially when > legal > > > compliance pretty much overrules this situation. > > > > > > [snip] > > > > > > Brian Proffitt > > > KIE mentor > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > -- > Saludos, Enrique González Martínez :) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
