________________________________________ From: Michael Brohl [[email protected]]
>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.
