________________________________________
From: Michael Brohl [michael.br...@ecomify.de]
Sent: Monday, March 07, 2022 2:22 AM
To: dev@ofbiz.apache.org
Subject: Re: New proposal on Jira to drop support for derby and use docker
instead
>Hi ? (no name given),
Hi there! :)
So let me try to summarize your response:
#1. The only reason to *keep* derby that you see is that we disagree on the
relative difficultly of getting a "simple build and run" going using docker vs
the difficulty of using the traditional "install java and follow the current
instructions" way
#2. You'd like me to start going through the list of all the issues that I
expect will end up as a derby constraint.
Is that correct?
As for our disagreeing on the relative difficulty between:
* installing docker and doing "docker pull ofbiz/demo" (for a demo) or "docker
pull ofbiz/release18.12" (for a production/development version)
* downloading ofbiz, going through the current instructions, trying to run it,
{then often downloading the correct version of java and doing it again}
Possible differences in our information could be:
* Perhaps there are other differences in how we are imagining the final docker
buildfiles to work for the various cases of #1 demo containers, #2 development
containers, and #3 production containers.
To be clear, one option for a development build/install is that the docker
buildfile could link the internal ofbiz directory to a directory on the
"master/local hard drive", meaning that you can edit the ofbiz code on the
local hard drive and rerun the docker container to run it. The java is still
installed inside the docker image, and the buildfile ensures its the correct
version, as well as handling all the other build details. (I see this as
easier for both the demo and the "simple build and run")
I guess a potential issue I see would be setting up a full eclipse debugging
environment, as eclipse won't display from inside the container (unless you
give the container special permissions), and I suspect that having eclipse
running outside the container will interfere with it's integrated debugging.
Are there any others?
* Perhaps we are differing in how difficult we believe it is to install
docker. I have not used docker on windows. Is docker difficult to install on
windows?
As for my first issue that I expect will end up as a derby constraint, I'll
start with my most recent issue that I run into regularly:
Before that, I should mention that I don't actually use derby so may be blaming
some things are derby that are undue, by misunderstanding some of its
abilities. So I'll state it as a question. It that relates to the table names
being mangled. For example: searching the list of tables on "employ" (to match
either "employee" or "employment") misses the tables containing employee
position because is is called "empl_position".
So my question is: are table names mangled like that because we have the
convention that index and constraint names include the tablename as a prefix,
and that not mangling the names would have exceeded a derby limit on number of
characters in a name?
Misc oddities:
> Derby is not for production use, we state this clearly in the README's and
> production setup guides.
Yep, and I gave ofbiz props for doing that in the phrase "Derby is already not
recommended for production systems (which is good)". :)
Best regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 06.03.22 um 23:20 schrieb Development:
> I added a new proposal on Jira . It is a proposal to drop support for derby
> and use docker instead (You'll need to read the issue/proposal for that to
> make sense) The issue is at:
> https://issues.apache.org/jira/browse/OFBIZ-12588
>
>
> This is a copy of the proposal:
>
> Derby is unique in the list of supported databases in that it lacks many
> features that normal databases support, leading to Jira issues like:
> https://issues.apache.org/jira/browse/OFBIZ-6138 . If you need specific
> examples just ask.
>
>
> Derby is already not recommended for production systems (which is good).
> I'm going to speculate that the reason derby is supported is to have a easy
> way for people to download ofbiz and "just run it" to get the demo running.
> Unfortunately this is not the case now as java is often not installed
> anymore, and when it is installed, it's often the wrong version of java for
> ofbiz.
>
>
> I propose that we drop support for Derby and instead allow people to get the
> demo easily running by making a official docker demo of the current stable
> version that just comes with postgres in the docker image. (docker image is
> being worked on here https://issues.apache.org/jira/browse/OFBIZ-10407 ).
> Instead of requiring java to be installed, it would require docker to be
> installed, but I believe the odds of success for a user are higher with
> docker then dealing with the java version incompatibilities.
>
> If you can think of a reason to keep derby after demos can be done through
> docker, please add your comments.
>
>
>
> CONFIDENTIALITY NOTICE: This message is intended only for the use of the
> person or organization to which it is addressed or was intended to be
> addressed, and may contain information that is privileged, confidential and
> exempt from disclosure under applicable law. If the reader of this message is
> not the intended recipient, or responsible for delivering the message to the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited. If you
> have received this communication in error, please notify the sender
> immediately by email and delete the original message immediately . The
> sender, its subsidiaries and affiliates, do not accept liability for any
> errors, omissions, corruption or virus in the contents of this message or any
> attachments that arise as a result of e-mail transmission. Thank you.
>
CONFIDENTIALITY NOTICE: This message is intended only for the use of the person
or organization to which it is addressed or was intended to be addressed, and
may contain information that is privileged, confidential and exempt from
disclosure under applicable law. If the reader of this message is not the
intended recipient, or responsible for delivering the message to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received this
communication in error, please notify the sender immediately by email and
delete the original message immediately . The sender, its subsidiaries and
affiliates, do not accept liability for any errors, omissions, corruption or
virus in the contents of this message or any attachments that arise as a result
of e-mail transmission. Thank you.
