Hello,
 I think Santa ... Emmm Tim is getting closer with EWB so 2021 will be EDB Year!

 Here's my wishlist:
 Log-structured merge-tree Indexes
 ZStd Compression

Post yours here!

> Post yours here!

I don't think there is enough space on the server for my wish list.

Besides, I've already started a conversation with Tim about future EDB enhancements so I get to be first in line.  

Terry,

> I don't think there is enough space on the server for my wish list.

Well, post the top ten here!

Terry


Ermm - have you forgotten all the suggestions / requests I've made over the years?

Roy Lambert

> Ermm - have you forgotten all the suggestions / requests I've made over the years?

Of course I haven't, I'm just substituting my position in line for whoever was in first.  

Terry


Right - since you do not have the good old British queuing gene I'm going to ask Tim to move to a ticketing system. I'll supply the roll of tickets ..... just after I've snaffled No. 1

Roy

Woops, I forgot the "Single File System/Container" suppoort to!

Michael,

<< I think Santa ... Emmm Tim is getting closer with EWB so 2021 will be EDB Year! >>

Yes, it will.

Here are some general points about EDB 3:

1) It will be single-file only and file-sharing access will finally have to go in favor of two modes: local, single-user or database server, multi-user.  This is necessary to alleviate the Windows SMB issues with multi-user file-sharing  and to permit more advanced locking/transaction architectures.

2) The engine itself is probably going to be closed-source or XE2 and higher only, with source code provided/available for the various clients (VCL, .NET, ODBC, PHP, etc).  It's starting to become way to cumbersome to support D5 -> 10.4 with the same set of source code, and I need to make it easier/quicker to get EDB builds out.  In addition, the EDB Manager will also be going closed-source or XE2 or higher only.

3) The engine is going to be split up into various pieces, so you will be able to, for example, just use the engine as a direct, local storage engine (without the SQL, user security, etc.) if you want.

4) The encryption will change along with the file format: AES for at-rest storage and TLS for network access to the database server.

Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,
You just know you are going to get feedback on this so I will get in first..

Here are some general points about EDB 3:

1) It will be single-file only and file-sharing access will finally have to go in favour of two modes: local, single-user or database server, multi-user.  This is necessary to alleviate the Windows SMB issues with multi-user file-sharing  and to permit more advanced locking/transaction architectures.

IB - I went C/S some time ago, bring it on.  A single file will be easier to manage from a file perspective.   ATT I can copy just a single file set, .edbtbl, .edbblb & .edbidx from one database to another.  Will this still be possible?

2) The engine itself is probably going to be closed-source or XE2 and higher only, with source code provided/available for the various clients (VCL, .NET, ODBC, PHP, etc).  It's starting to become way to cumbersome to support D5 -> 10.4 with the same set of source code, and I need to make it easier/quicker to get EDB builds out.

IB - XE2 & up pls.  Much prefer to have the source available, even if I am not using it.

>>  In addition, the EDB Manager will also be going closed-source or XE2 or higher only.

IB - Absolutely XE2 & up - I use the Manager source as the core of my own Manager I supply to my Customers.

3) The engine is going to be split up into various pieces, so you will be able to, for example, just use the engine as a direct, local storage engine (without the SQL, user security, etc.) if you want.

IB - Interesting.  I am not sure what exactly this will mean until I see it in the flesh.

4) The encryption will change along with the file format: AES for at-rest storage and TLS for network access to the database server.

IB - AES 256bit?

IB - Any improvement in the compression algorithm for Backups?

Looking forward to EDB3.

Regards,
Ian

Tim Young [Elevate Software] wrote:

Michael,

<< I think Santa ... Emmm Tim is getting closer with EWB so 2021 will be EDB Year! >>

Yes, it will.

Here are some general points about EDB 3:

>>

I guess the list does not stop on those four right ?

If you manage to have a Single File Database with Log-structured merge-tree Indexes (aka RocksDB) with Multi-OS support it will be the First DB with those futures easily get a large amount of SQLlite developers ....
(Since most PC nowadays are using SDD and mobiles are having Flash memories)

Just think about that