You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Development <D...@dlsemc.com.INVALID> on 2022/03/06 22:20:55 UTC
New proposal on Jira to drop support for derby and use docker instead
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.
Re: New proposal on Jira to drop support for derby and use docker instead
Posted by Michael Brohl <mi...@ecomify.de>.
Hi,
inline...
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 08.03.22 um 19:11 schrieb Development:
> I just don't see the necessity to drop Derby support and exclude those people who do not want to use Docker (for whatever reason) or need the current OOTB behaviour.
> "need the current OOTB behaviour" is a interesting point. Like even though ofbiz documentation says to not use derby in production, it's possible that people actually are. I had not thought of that.
> Do we have any way to figure out if people are actually doing that?
The advantage of the embedded Derby is that the database is wiped and
rebuild/loaded with data fast and easy because the database files are
simply deleted and rebuild. No extra dependency on another database,
configuration or external container.
There are several scenarios where it is used, mostly during development
and release management:
- OFBiz standard development (I always develop/test against the latest
code incl. the latest demo data).
- continuous build/tests (buildbot, Jenkins etc.)
- check of the dist files for a new release
(download/unzip/build/testIntegration)
- quick check of the latest trunk/release branch version with the
original load data
- OFBiz demo instances, which are reset every night
- ...
I do not speak about production use and as far as I understand, you were
talking about providing a demo for new users.
So providing a Docker demo might help to get new users started easily.
This can be achieved without changing the OOTB behaviour and dropping
Derby support as proposed.
RE: New proposal on Jira to drop support for derby and use docker instead
Posted by Development <D...@dlsemc.com.INVALID>.
________________________________________
From: Michael Brohl [michael.brohl@ecomify.de]
>Am 07.03.22 um 18:44 schrieb Development:
>> 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?
>
>I don't think I have said anything like that.
Ok, must be a misunderstanding. I thought the relevant threading was:
>>>>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.
>>>I don't see a reason to DROP the derby support in OFBiz and replace it with docker
>>#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.
and
>>>>If you can think of a reason to keep derby after demos can be done through docker, please add your comments.
>>>In our experience, users already have problems with the simple build and run OFBiz offers, it is not reasonable to make this more difficult for them by having to install and run docker and OFBiz within.
>> #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
on to next topic:
>What I said was that it is not necessary to drop Derby support to provide the additional option for a Docker image.
Correct, it is not *necessary* to drop Derby support to provide the additional option for a Docker image. That's not in dispute. I was proposing that slight extensions of the current docker initiatives could make it so that we *can* drop derby.
>> * 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?
>
>I am not using Windows so I cannot tell. I'm using Docker on Mac.
>
>As you can see in https://issues.apache.org/jira/browse/OFBIZ-10407 , I have provided a Docker image to be used so I'm familiar with Docker and see it as a good additional way to provide a demo system for interested
users.
Yes, as referenced in my original email with the phrase "docker image is being worked on here https://issues.apache.org/jira/browse/OFBIZ-10407"
By the way, thanks for your work on that.
>I just don't see the necessity to drop Derby support and exclude those people who do not want to use Docker (for whatever reason) or need the current OOTB behaviour.
"need the current OOTB behaviour" is a interesting point. Like even though ofbiz documentation says to not use derby in production, it's possible that people actually are. I had not thought of that.
Do we have any way to figure out if people are actually doing that?
>> 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 nto regularly:
>> Before that, I should mention that I don't actually use derby so may be blaming some things are derby that are ndue, 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?
>
>I do not know exactly why each table has his name. But in your example,
>I would simply search for "empl" and would find what I need...
Not relevant to the point, but note that your solution requires the person searching to know the results of the search before they search.
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.
Re: New proposal on Jira to drop support for derby and use docker instead
Posted by Michael Brohl <mi...@ecomify.de>.
Please see my responses inline...
Regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 07.03.22 um 18:44 schrieb Development:
> 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?
I don't think I have said anything like that.
What I said was that it is not necessary to drop Derby support to
provide the additional option for a Docker image.
> * 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?
I am not using Windows so I cannot tell. I'm using Docker on Mac.
As you can see in https://issues.apache.org/jira/browse/OFBIZ-10407 , I
have provided a Docker image to be used so I'm familiar with Docker and
see it as a good additional way to provide a demo system for interested
users.
I just don't see the necessity to drop Derby support and exclude those
people who do not want to use Docker (for whatever reason) or need the
current OOTB behaviour.
> 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?
I do not know exactly why each table has his name. But in your example,
I would simply search for "empl" and would find what I need...
Re: New proposal on Jira to drop support for derby and use docker instead
Posted by Scott Gray <sc...@hotwaxsystems.com>.
>
> 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?
FWIW I believe the 30 character table name limit originated with Oracle and
not Derby. I'm not sure if Oracle still has that constraint.
Regards
Scott
On Tue, 8 Mar 2022 at 06:45, Development <D...@dlsemc.com.invalid> wrote:
>
> ________________________________________
> From: Michael Brohl [michael.brohl@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.
>
RE: New proposal on Jira to drop support for derby and use docker instead
Posted by Development <D...@dlsemc.com.INVALID>.
________________________________________
From: Michael Brohl [michael.brohl@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.
Re: New proposal on Jira to drop support for derby and use docker instead
Posted by Michael Brohl <mi...@ecomify.de>.
Hi ? (no name given),
I don't see a reason to DROP the derby support in OFBiz and replace it
with docker. What we can and should do is to offer is a docker demo
besides this. There are already initiatives to do this.
In our experience, users already have problems with the simple build and
run OFBiz offers, it is not reasonable to make this more difficult for
them by having to install and run docker and OFBiz within.
Derby is not for production use, we state this clearly in the README's
and production setup guides. It is for demo purposes and easily
repeatable cleanAll/load scenarios which are also uses by buildbot for
the official demos..
If you not just want to have a brief look at the Demos, you'll have to
install Java anyway.
To use and load data into OFBiz, there is nothing more to do than
configuration in the entityengine.xml file as for any other database.
Derby is just the default.
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.
>