[discussion] future embedded DB in AOO

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[discussion] future embedded DB in AOO

Peter Kovacs-3
Hi all,

I would like to know how you guys feel we should move on with our base
Database. Our current strategy is a small sized embedded DB using HSQLDB
(BSD). There are 2 other options in the same weight class, that is H2
(EPL1 or MPL2) and Apache Derby (AL2).

Something like SQLLite (PublicDomain) could be technical interesting,
but I think their licensing is not so appealing.

We could also consider firebird (MPL) like LO, but I have the impression
that this is not a lightweight DB, but featurerich. And I wonder if this
is really something we should provide. I would rather develop a way to
make it easy to switch the DB when a Project grows.

What are your thoughts?


All the Best

Peter


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] future embedded DB in AOO

Mechtilde Stehmann-2
Hello Peter,

Am 07.12.20 um 19:38 schrieb Peter Kovacs:
> Hi all,
>
> I would like to know how you guys feel we should move on with our base
> Database. Our current strategy is a small sized embedded DB using HSQLDB
> (BSD). There are 2 other options in the same weight class, that is H2
> (EPL1 or MPL2) and Apache Derby (AL2).

I prefer H2by several reasens:
1. H2 is the continued deelopment of HSQLDB
2. H2 is also used in other applications like Hibiscus (and JVerein ;-))
3. I know also some proprietary software which use it as an embedded DB

kind regards

Mechtilde

>
> Something like SQLLite (PublicDomain) could be technical interesting,
> but I think their licensing is not so appealing.
>
> We could also consider firebird (MPL) like LO, but I have the impression
> that this is not a lightweight DB, but featurerich. And I wonder if this
> is really something we should provide. I would rather develop a way to
> make it easy to switch the DB when a Project grows.
>
> What are your thoughts?
>
>
> All the Best
>
> Peter
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
--
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F


OpenPGP_signature (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: [discussion] future embedded DB in AOO

Jörg Schmidt-2
In reply to this post by Peter Kovacs-3
Hello,

> -----Original Message-----
> From: Peter Kovacs [mailto:[hidden email]]
> Sent: Monday, December 07, 2020 7:38 PM
> To: [hidden email]
> Subject: [discussion] future embedded DB in AOO
>
> Hi all,
>
> I would like to know how you guys feel we should move on with
> our base
> Database. ...

There is no compelling reason for us to join LO on the database issue, it may even be strategically smart not to.

I know neither H2 nor Apache Derby and have only briefly checked Wikipedia and if these two were available I would be in favour of Derby, because:
-obviously better support for SQL
-maybe, due to the longer history, the more mature system
-apparently better encryption features
-Apache Project

But maybe there is an argument for H2:
this project seems to be, in essence, driven by a single developer, most likely the one who would welcome H2 to become more known when we use it in AOO and would be willing to coordinate the development of H2 with us, so that H2 adapts to the requirements of AOO in the best possible way.


With both databases, however, Java bothers me - or have we given up the intention of making AOO less dependent on Java?
(yes, of course this is a very long-term question)




greetings,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] future embedded DB in AOO

Jim Jagielski
In reply to this post by Peter Kovacs-3


> On Dec 7, 2020, at 1:38 PM, Peter Kovacs <[hidden email]> wrote:
>
> Hi all,
>
> I would like to know how you guys feel we should move on with our base Database. Our current strategy is a small sized embedded DB using HSQLDB (BSD). There are 2 other options in the same weight class, that is H2 (EPL1 or MPL2) and Apache Derby (AL2).
>
> Something like SQLLite (PublicDomain) could be technical interesting, but I think their licensing is not so appealing.

Is EPL1/MPL2 more appealing than SQLite's PD?


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [discussion] future embedded DB in AOO

Jörg Schmidt-2
In reply to this post by Mechtilde Stehmann-2
Hello,

> -----Original Message-----
> From: Mechtilde [mailto:[hidden email]]
> Sent: Monday, December 07, 2020 8:11 PM
> To: [hidden email]
> Subject: Re: [discussion] future embedded DB in AOO
>
> Hello Peter,
>
> Am 07.12.20 um 19:38 schrieb Peter Kovacs:
> > Hi all,
> >
> > I would like to know how you guys feel we should move on
> with our base
> > Database. Our current strategy is a small sized embedded DB
> using HSQLDB
> > (BSD). There are 2 other options in the same weight class,
> that is H2
> > (EPL1 or MPL2) and Apache Derby (AL2).
>
> I prefer H2by several reasens:
> 1. H2 is the continued deelopment of HSQLDB
> 2. H2 is also used in other applications like Hibiscus (and
> JVerein ;-))
> 3. I know also some proprietary software which use it as an
> embedded DB

If I read wikipedia the SQL support seems to be worse (in the sense of incomplete) for H2 than for Derby.
Is there anything more to say about this? (Maybe the impression I get from wikipedia is deceptive?)


greetings,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[discussion] future embedded DB in AOO

Mechtilde Stehmann-2
In reply to this post by Peter Kovacs-3
Hello Peter,

Am 07.12.20 um 19:38 schrieb Peter Kovacs:
> Hi all,
>
> I would like to know how you guys feel we should move on with our base
> Database. Our current strategy is a small sized embedded DB using HSQLDB
> (BSD). There are 2 other options in the same weight class, that is H2
> (EPL1 or MPL2) and Apache Derby (AL2).

I prefer H2by several reasens:
1. H2 is the continued deelopment of HSQLDB
2. H2 is also used in other applications like Hibiscus (and JVerein ;-))
3. I know also some properity software which use it as an embedded DB

kind regards

Mechtilde

>
> Something like SQLLite (PublicDomain) could be technical interesting,
> but I think their licensing is not so appealing.
>
> We could also consider firebird (MPL) like LO, but I have the impression
> that this is not a lightweight DB, but featurerich. And I wonder if this
> is really something we should provide. I would rather develop a way to
> make it easy to switch the DB when a Project grows.
>
> What are your thoughts?
>
>
> All the Best
>
> Peter
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
--
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F




OpenPGP_signature (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [discussion] future embedded DB in AOO

Jim Jagielski
In reply to this post by Jörg Schmidt-2
I agree that eating our own dogfood and using Derby would be the "better" path to take; plus it is relatively small while at the same time being quite powerful and compliant.

> On Dec 7, 2020, at 2:46 PM, Jörg Schmidt <[hidden email]> wrote:
>
> Hello,
>
>> -----Original Message-----
>> From: Peter Kovacs [mailto:[hidden email]]
>> Sent: Monday, December 07, 2020 7:38 PM
>> To: [hidden email]
>> Subject: [discussion] future embedded DB in AOO
>>
>> Hi all,
>>
>> I would like to know how you guys feel we should move on with
>> our base
>> Database. ...
>
> There is no compelling reason for us to join LO on the database issue, it may even be strategically smart not to.
>
> I know neither H2 nor Apache Derby and have only briefly checked Wikipedia and if these two were available I would be in favour of Derby, because:
> -obviously better support for SQL
> -maybe, due to the longer history, the more mature system
> -apparently better encryption features
> -Apache Project
>
> But maybe there is an argument for H2:
> this project seems to be, in essence, driven by a single developer, most likely the one who would welcome H2 to become more known when we use it in AOO and would be willing to coordinate the development of H2 with us, so that H2 adapts to the requirements of AOO in the best possible way.
>
>
> With both databases, however, Java bothers me - or have we given up the intention of making AOO less dependent on Java?
> (yes, of course this is a very long-term question)
>
>
>
>
> greetings,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [discussion] future embedded DB in AOO

Jim Jagielski
In reply to this post by Jörg Schmidt-2


> On Dec 7, 2020, at 2:46 PM, Jörg Schmidt <[hidden email]> wrote:
>
> With both databases, however, Java bothers me - or have we given up the intention of making AOO less dependent on Java?
> (yes, of course this is a very long-term question)

But still a good one... personally, SQlite seems like a better, more strategic, option with that in mind.
Reply | Threaded
Open this post in threaded view
|

Re: [discussion] future embedded DB in AOO

Peter Kovacs-3
In reply to this post by Jim Jagielski

On 07.12.20 20:48, Jim Jagielski wrote:
>
>> On Dec 7, 2020, at 1:38 PM, Peter Kovacs <[hidden email]> wrote:
>>
>> Hi all,
>>
>> I would like to know how you guys feel we should move on with our base Database. Our current strategy is a small sized embedded DB using HSQLDB (BSD). There are 2 other options in the same weight class, that is H2 (EPL1 or MPL2) and Apache Derby (AL2).
>>
>> Something like SQLLite (PublicDomain) could be technical interesting, but I think their licensing is not so appealing.
> Is EPL1/MPL2 more appealing than SQLite's PD?

No not really. I am intimidated by the statements:

    Open-Source, not Open-Contribution

    SQLite is open-source, meaning that you can make as many copies of
    it as you want and do whatever you want with those copies, without
    limitation. But SQLite is not open-contribution. In order to keep
    SQLite in the public domain and ensure that the code does not become
    contaminated with proprietary or licensed content, the project does
    not accept patches from unknown persons.

    All of the code in SQLite is original, having been written
    specifically for use by SQLite. No code has been copied from unknown
    sources on the internet.

    Contributed Code

    In order to keep SQLite completely free and unencumbered by
    copyright, the project does not accept patches. If you would like to
    make a suggested change, and include a patch as a proof-of-concept,
    that would be great. However please do not be offended if we rewrite
    your patch from scratch.

Actually their Licensing is:

    Anyone is free to copy, modify, publish, use, compile, sell, or
    distribute the original SQLite code, either in source code form or
    as a compiled binary, for any purpose, commercial or non-commercial,
    and by any means.

Which is fine and works for us.
Reply | Threaded
Open this post in threaded view
|

RE: [discussion] future embedded DB in AOO

Jörg Schmidt-2
In reply to this post by Jim Jagielski
> -----Original Message-----
> From: Jim Jagielski [mailto:[hidden email]]
> Sent: Monday, December 07, 2020 10:11 PM
> To: dev
> Subject: Re: [discussion] future embedded DB in AOO
>
> I agree that eating our own dogfood and using Derby would be
> the "better" path to take; plus it is relatively small while
> at the same time being quite powerful and compliant.

As already written: I don't know both systems and I only made my statement based on the information I found on Wikipedia.
If Mechtilde (and others) have real experience with one of the two databases, this would have more weight.

Maybe one more thing: Is the problem database even important?
LO, for example, has much more manpower than we do, and yet Firebird in LO still seems to me to be a construction site, because actually everyone advises me to stay with HSQLDB (as far as an embedded DB is concerned).
AOO should avoid getting into the same situation, because invested work that ultimately creates no benefit for the user is badly invested.

Yes, it is a very soft argument to warn not to start at all, because you are afraid, that you can not make it.
But many other questions seem to me to be more urgent, e.g. the currently detected problems with Big Sur (maybe other MacOS versions?)  



Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] future embedded DB in AOO

Peter Kovacs-3

On 07.12.20 22:35, Jörg Schmidt wrote:

>> -----Original Message-----
>> From: Jim Jagielski [mailto:[hidden email]]
>> Sent: Monday, December 07, 2020 10:11 PM
>> To: dev
>> Subject: Re: [discussion] future embedded DB in AOO
>>
>> I agree that eating our own dogfood and using Derby would be
>> the "better" path to take; plus it is relatively small while
>> at the same time being quite powerful and compliant.
> As already written: I don't know both systems and I only made my statement based on the information I found on Wikipedia.
> If Mechtilde (and others) have real experience with one of the two databases, this would have more weight.
>
> Maybe one more thing: Is the problem database even important?
We cannot build with Java 11 and up. Decisions have to be made soon.
Strategy has to be setup. A Roadmap would be great
> LO, for example, has much more manpower than we do, and yet Firebird in LO still seems to me to be a construction site, because actually everyone advises me to stay with HSQLDB (as far as an embedded DB is concerned).
More Manpower does not mean they invest it into Base. So I would not
judge on our strength or weakness.
> AOO should avoid getting into the same situation, because invested work that ultimately creates no benefit for the user is badly invested.
That statement is true but incomplete. We need to take into account how
much work it is for us to maintain an embedded DB. The DB eats our
resources. A good choice can make a difference in the future.
> Yes, it is a very soft argument to warn not to start at all, because you are afraid, that you can not make it.
> But many other questions seem to me to be more urgent, e.g. the currently detected problems with Big Sur (maybe other MacOS versions?)

Well, there are always more important topics. I want to take some time,
develop some strategy Maybe a roadmap. Maybe it is a good Idea to check
the options a bit. Maybe even to have something to talk about on next
FOSDEM.

We have a Room and a Deadline and no talks yet. :)

I just want to know how everyone feels on this topic, since we need to
make a decision someday.




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] future embedded DB in AOO

Jim Jagielski
In reply to this post by Peter Kovacs-3


> On Dec 7, 2020, at 4:27 PM, Peter Kovacs <[hidden email]> wrote:
>
>
> On 07.12.20 20:48, Jim Jagielski wrote:
>>
>>> On Dec 7, 2020, at 1:38 PM, Peter Kovacs <[hidden email]> wrote:
>>>
>>> Hi all,
>>>
>>> I would like to know how you guys feel we should move on with our base Database. Our current strategy is a small sized embedded DB using HSQLDB (BSD). There are 2 other options in the same weight class, that is H2 (EPL1 or MPL2) and Apache Derby (AL2).
>>>
>>> Something like SQLLite (PublicDomain) could be technical interesting, but I think their licensing is not so appealing.
>> Is EPL1/MPL2 more appealing than SQLite's PD?
>
> No not really. I am intimidated by the statements:
>
>   Open-Source, not Open-Contribution
>
>   SQLite is open-source, meaning that you can make as many copies of
>   it as you want and do whatever you want with those copies, without
>   limitation. But SQLite is not open-contribution. In order to keep
>   SQLite in the public domain and ensure that the code does not become
>   contaminated with proprietary or licensed content, the project does
>   not accept patches from unknown persons.
>
>   All of the code in SQLite is original, having been written
>   specifically for use by SQLite. No code has been copied from unknown
>   sources on the internet.
>
>   Contributed Code
>
>   In order to keep SQLite completely free and unencumbered by
>   copyright, the project does not accept patches. If you would like to
>   make a suggested change, and include a patch as a proof-of-concept,
>   that would be great. However please do not be offended if we rewrite
>   your patch from scratch.
>
> Actually their Licensing is:
>
>   Anyone is free to copy, modify, publish, use, compile, sell, or
>   distribute the original SQLite code, either in source code form or
>   as a compiled binary, for any purpose, commercial or non-commercial,
>   and by any means.
>
> Which is fine and works for us.

Also, let's look at https://www.apache.org/legal/resolved.html

Works in the public domain (or covered by a license treated similarly) may be included within Apache products. Attribution is required (in a similar fashion to the Category A list.

A work should be treated as being in the public domain when one of the following applies:

the work is covered by
the Creative Commons Public Domain Mark <http://creativecommons.org/publicdomain/mark/1.0/>, or
a suitable dedication (to the public domain) by the authors; or


I think we can confidently affirm the 2nd bullet.
Reply | Threaded
Open this post in threaded view
|

Re: [discussion] future embedded DB in AOO

Peter Kovacs-3

On 07.12.20 23:03, Jim Jagielski wrote:

>
>> On Dec 7, 2020, at 4:27 PM, Peter Kovacs <[hidden email]> wrote:
>>
>>
>> On 07.12.20 20:48, Jim Jagielski wrote:
>>>> On Dec 7, 2020, at 1:38 PM, Peter Kovacs <[hidden email]> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I would like to know how you guys feel we should move on with our base Database. Our current strategy is a small sized embedded DB using HSQLDB (BSD). There are 2 other options in the same weight class, that is H2 (EPL1 or MPL2) and Apache Derby (AL2).
>>>>
>>>> Something like SQLLite (PublicDomain) could be technical interesting, but I think their licensing is not so appealing.
>>> Is EPL1/MPL2 more appealing than SQLite's PD?
>> No not really. I am intimidated by the statements:
>>
>>    Open-Source, not Open-Contribution
>>
>>    SQLite is open-source, meaning that you can make as many copies of
>>    it as you want and do whatever you want with those copies, without
>>    limitation. But SQLite is not open-contribution. In order to keep
>>    SQLite in the public domain and ensure that the code does not become
>>    contaminated with proprietary or licensed content, the project does
>>    not accept patches from unknown persons.
>>
>>    All of the code in SQLite is original, having been written
>>    specifically for use by SQLite. No code has been copied from unknown
>>    sources on the internet.
>>
>>    Contributed Code
>>
>>    In order to keep SQLite completely free and unencumbered by
>>    copyright, the project does not accept patches. If you would like to
>>    make a suggested change, and include a patch as a proof-of-concept,
>>    that would be great. However please do not be offended if we rewrite
>>    your patch from scratch.
>>
>> Actually their Licensing is:
>>
>>    Anyone is free to copy, modify, publish, use, compile, sell, or
>>    distribute the original SQLite code, either in source code form or
>>    as a compiled binary, for any purpose, commercial or non-commercial,
>>    and by any means.
>>
>> Which is fine and works for us.
> Also, let's look at https://www.apache.org/legal/resolved.html
>
> Works in the public domain (or covered by a license treated similarly) may be included within Apache products. Attribution is required (in a similar fashion to the Category A list.
>
> A work should be treated as being in the public domain when one of the following applies:
>
> the work is covered by
> the Creative Commons Public Domain Mark <http://creativecommons.org/publicdomain/mark/1.0/>, or
> a suitable dedication (to the public domain) by the authors; or
>
>
> I think we can confidently affirm the 2nd bullet.
thanks Jim. I was not that sure about this point.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] future embedded DB in AOO

Damjan Jovanovic
In reply to this post by Peter Kovacs-3
On Mon, Dec 7, 2020 at 8:38 PM Peter Kovacs <[hidden email]> wrote:

> Hi all,
>
> I would like to know how you guys feel we should move on with our base
> Database. Our current strategy is a small sized embedded DB using HSQLDB
> (BSD). There are 2 other options in the same weight class, that is H2
> (EPL1 or MPL2) and Apache Derby (AL2).
>
> Something like SQLLite (PublicDomain) could be technical interesting,
> but I think their licensing is not so appealing.
>
> We could also consider firebird (MPL) like LO, but I have the impression
> that this is not a lightweight DB, but featurerich. And I wonder if this
> is really something we should provide. I would rather develop a way to
> make it easy to switch the DB when a Project grows.
>
> What are your thoughts?
>
>
Whatever we do, we have to provide backward compatibility for HSQLDB.

I am more interested in something like Apache Calcite, which would let us
do SQL queries spanning multiple database backends, than in yet another
database backend.

SQLite is interesting because it's very widely used, runs on iPhone and
Android, is a single file, performs well, and is lightweight.

The hard part is getting the database to write into .ODB files instead of
what it natively uses?

Damjan
Reply | Threaded
Open this post in threaded view
|

Re: [discussion] future embedded DB in AOO

Keith N. McKenna
In reply to this post by Peter Kovacs-3
On 12/7/2020 1:38 PM, Peter Kovacs wrote:

> Hi all,
>
> I would like to know how you guys feel we should move on with our base
> Database. Our current strategy is a small sized embedded DB using HSQLDB
> (BSD). There are 2 other options in the same weight class, that is H2
> (EPL1 or MPL2) and Apache Derby (AL2).
>
> Something like SQLLite (PublicDomain) could be technical interesting,
> but I think their licensing is not so appealing.
>
> We could also consider firebird (MPL) like LO, but I have the impression
> that this is not a lightweight DB, but featurerich. And I wonder if this
> is really something we should provide. I would rather develop a way to
> make it easy to switch the DB when a Project grows.
>
> What are your thoughts?
>
>
> All the Best
>
> Peter
My first question has to be : Why are we still using such an old version
of HSQLDB? As memory serves it is `1.8.0 and the latest release of
HSQLDB is 2.5.1.

Second is why cannot we upgrade to HSQLDB 2.X.

As a process engineer and not a programmer these are simple questions I
need answers for to intelligently contribute to this discussion. Thanks
all for your understanding.

Regards
Keith.


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: [discussion] future embedded DB in AOO

Jörg Schmidt-2
In reply to this post by Peter Kovacs-3
 

> -----Original Message-----
> From: Peter Kovacs [mailto:[hidden email]]
> Sent: Monday, December 07, 2020 11:03 PM
> To: [hidden email]
> Subject: Re: [discussion] future embedded DB in AOO

> > Maybe one more thing: Is the problem database even important?
> We cannot build with Java 11 and up. Decisions have to be made soon.
> Strategy has to be setup. A Roadmap would be great

Peter, I do not understand what that means in concrete terms.

IF Java is a critical factor (I guess because of Oracle's licensing policy) why is it less so for H2 or Derby than for HSQLDB?
Actually we should rather choose a database that works without Java(?)

Also: IF the Java question is urgent, why is it only for Base? Doesn't belong then on the agenda anymore?

> I want to take
> some time,
> develop some strategy Maybe a roadmap.

IF it's a strategy we should probably talk about Java and not only about Base.


greetings,
Jörg






---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [discussion] future embedded DB in AOO

Jörg Schmidt-2
In reply to this post by Keith N. McKenna
> -----Original Message-----
> From: Keith N. McKenna [mailto:[hidden email]]
> Sent: Tuesday, December 08, 2020 3:49 AM
> To: [hidden email]
> Subject: Re: [discussion] future embedded DB in AOO

> My first question has to be : Why are we still using such an
> old version
> of HSQLDB? As memory serves it is `1.8.0 and the latest release of
> HSQLDB is 2.5.1.
>
> Second is why cannot we upgrade to HSQLDB 2.X.
>
> As a process engineer and not a programmer these are simple
> questions I
> need answers for to intelligently contribute to this
> discussion. Thanks
> all for your understanding.

indeed, one should not leave out these questions.



Jörg



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [discussion] future embedded DB in AOO

Jörg Schmidt-2
In reply to this post by Jörg Schmidt-2
> -----Original Message-----
> From: Jörg Schmidt [mailto:[hidden email]]
> Sent: Tuesday, December 08, 2020 9:14 AM
> To: [hidden email]
> Subject: RE: [discussion] future embedded DB in AOO
>
>  
> [...]

Now I have to focus again:

Is the concrete problem Base or Java?

IF it is Java why are we even talking about replacing HSQLDB with Java-based databases?
Shouldn't our goal then be to find a database that is not based on Java?


Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] future embedded DB in AOO

Peter Kovacs-3
In reply to this post by Jörg Schmidt-2

On 08.12.20 09:14, Jörg Schmidt wrote:

>  
>
>> -----Original Message-----
>> From: Peter Kovacs [mailto:[hidden email]]
>> Sent: Monday, December 07, 2020 11:03 PM
>> To: [hidden email]
>> Subject: Re: [discussion] future embedded DB in AOO
>>> Maybe one more thing: Is the problem database even important?
>> We cannot build with Java 11 and up. Decisions have to be made soon.
>> Strategy has to be setup. A Roadmap would be great
> Peter, I do not understand what that means in concrete terms.
>
> IF Java is a critical factor (I guess because of Oracle's licensing policy) why is it less so for H2 or Derby than for HSQLDB?

No, I meant that building OpenOffice with Java 11 and later causes the
build to break on hsqldb. So we need to talk

what we do. Current state is that we need to change the code in order to
build on a later Java Version. That is what brought this topic up. And
again I want to have a discussion on what we head out for. What is
needed. And I think this makes it a good time to collect all opinions,
arguments and requirements.

> Actually we should rather choose a database that works without Java(?)
>
> Also: IF the Java question is urgent, why is it only for Base? Doesn't belong then on the agenda anymore?

Where do I say it is urgent? I say we should take some time and consider
our options. Making a sound decision.

This takes time. It is a good time to start this now.

>
>> I want to take
>> some time,
>> develop some strategy Maybe a roadmap.
> IF it's a strategy we should probably talk about Java and not only about Base.
What is your opinion on Java? Not that I want to start a general Java
discussion, but you are right they are connected.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] future embedded DB in AOO

Peter Kovacs-3
In reply to this post by Jörg Schmidt-2

On 08.12.20 09:27, Jörg Schmidt wrote:
>> -----Original Message-----
>> From: Keith N. McKenna [mailto:[hidden email]]
>> Sent: Tuesday, December 08, 2020 3:49 AM
>> To: [hidden email]
>> Subject: Re: [discussion] future embedded DB in AOO
>> My first question has to be : Why are we still using such an
>> old version
>> of HSQLDB? As memory serves it is `1.8.0 and the latest release of
>> HSQLDB is 2.5.1.

I thought we had discussion on this, but I could not find them.

I will have later a second look. But this is a good thought. How much
time will an upgrade bring us?

It will influence the roadmap for sure.

>>
>> Second is why cannot we upgrade to HSQLDB 2.X.

The question is not if we can, the question is if it is worth it.

I would like to take an early opportunity to look beyond the immediate
need of  keep things working.

I put on the question what alternative exists. Jörg brought up the
Question how much Java do we want in future?

>> As a process engineer and not a programmer these are simple
>> questions I
>> need answers for to intelligently contribute to this
>> discussion. Thanks
>> all for your understanding.

All opinion and thoughts are welcome. I want to find out where we want
to head with the embedded DB. All Ideas and reasoning can bring up good
Views.

We can also discuss where we want to go with Base. The question is
Connected. And Base needs some love, don't you think?


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12