Hi Daniel, IMO, splitting entityengine.xml file into db-specific is good in general.
I have the following suggestions: Gradle Allow more 1 db driver to be downloaded. Different datasource can be in use at the same time, like mysql for olap and postgreql for others. Non-Gradle Allow ENTITY_ENGINE_XML_FILENAME=entityengine.xml in EntityConfig class to be configurable. So we can switch to use entityengine.postgres.xml, entityengine.derby.xml, etc. Regards, James On 2021/01/12 10:28:38, Daniel Watford <d...@foomoo.co.uk> wrote: > Hello, > > I'd like to get opinions from the devs on whether it is worth pursuing > changes to include database driver resolution in ofbiz builds. > > PR246 (https://github.com/apache/ofbiz-framework/pull/246) was an > experiment to try and configure an instance of ofbiz from the gradle build, > covering database driver resolution and populating entityengine.xml with > username, password, etc needed to access a DBMS. > > I've since learned about how ofbiz uses the Application gradle plugin to > create distributions (distTar / distZip) where it probably wouldn't be > appropriate to embed username and password at build time. Therefore I don't > think it is worth pursuing use of build-time properties to configure > database access. > > However I do wonder if it is still worth using a build-time property to > target a build and its distributions for use with a particular DBMS type > (mysql, postgres, etc). Although they wouldn't be distributed by Apache, > another party might then be able to then create and host ofbiz > distributions for each of the major DBMS platforms, with the appropriate > client access DBMS library already included. I think this would assist in > creation of container images targeting different databases too. > > We already specify versions of all other ofbiz dependencies, but we don't > specify the versions of DBMS access libraries that should be used. This > creates an extra deployment step for an ofbiz administrator and might > potentially be a source of confusion. > > By making DBMS choice a build-time property we can declare, in code, which > libraries are officially supported by the project. > > If this is worth pursuing the next step will be to identify the database > driver versions used by the community for their ofbiz deployments. > > Please let me know what you think. > > Thanks, > > Dan > > On Mon, 30 Nov 2020 at 20:45, Daniel Watford <d...@foomoo.co.uk> wrote: > > > Hello, > > > > I'ved added a PR for OFBIZ-12081 where I add a gradle runtime dependency > > to download a specific database driver. Currently I have only added a > > driver for Postgres, but it should be simple to nominate drivers for other > > DBMS where they can be downloaded and distributed. > > > > Are there any issues with having an ofbiz 'approved' version of a database > > driver specified as part of the ofbiz build process? > > > > If this is a reasonable thing to do please nominate dependencies for the > > other DBMS supported by ofbiz. > > > > The same PR also adds a new build task to modify values in > > entityengine.xml corresponding to the DBMS selected in gradle.properties. > > > > I propose these additions to support building multiple varieties of docker > > images which are pre-loaded with the database driver for a particular DBMS. > > These pre-configured docker images can then be used as part of ofbiz > > published docker-compose specifications which couple a docker image with a > > particular DBMS, all running in their own containers. > > > > Please let me know if there are any concerns with pre-configuring builds > > in this way. > > > > Thanks, > > > > Dan. > > > > -- > > Daniel Watford > > > > > -- > Daniel Watford >
