Red Database 2.1 released – merge ideas
Hello, Dear Firebird Team Members!
After almost two years in development, four betas and four release
candidates, Red Database 2.1 is finally released.
Information about the release is present here:
http://www.red-soft.biz/en/index.html
We are not interested at all in forking basic engine functionality, so
here are my thoughts on what major features Red Database engine has, and
how they can me merged into Firebird:
SuperClassic engine
~~~~~~~~~~~~~~
We’re pretty much in sync with Firebird HEAD regarding this feature.
Roman Simakov and our QA team collaborate very effectively with Dmitry
Emanov. Nothing special needs to be done.
Java Stored Procedures
~~~~~~~~~~~~~~~~
Implementation is based on the same original ideas as ExtEngines branch
and earlier implementations, is simple and rugged. Can serve as proof of
concept implementation.
As ExtEngines work progresses parts of our infrastructure should become
unnecessary and the feature should converge into single code base.
We hope that Eugeny Putilin collaborates further with Firebird team, so
Firebird project can gain from our experience (and maybe replicate our
system tables structure).
While testing we gained quite a bit of understanding of JRE behaviors in
different circumstances.
Full-Text Search
~~~~~~~~~~~~
From Firebird project point of view, this is very experimental feature,
which shows how complete working full-text-search can be implemented for
Firebird.
I ask project members to review it from the architectural standpoint. It
is implemented as ESPs in Java. When the feature becomes architecturally
stable, we may want to migrate it to Lucene C.
Again, Eugeny Putilin have done most of the work, and should be in a
position to help.
PSQL debugger for SP/triggers
~~~~~~~~~~~~~~~~~~~~~
Proof of concept implementation, which currently uses CORBA for
communication with debugger on the client side, and server-side debugger
engine implemented in Java. We have discussed with Eugeny that Y-Valve
can be extended to accomodate communication with debugger via the
variety of supported protocols (INET, XNET, etc). Server-side Java
helper on the server side becomes unnecessary in this case. We’re not
planning to extend it much further from what is done now, but debugger
API works, in can be re-worked and polished by the community and user
tools developers.
Security features
~~~~~~~~~~~
The feature set aims to ensure complete coverage of ISO 27000 standard
requirements which can be implemented by the database engine.
There are similar projects for PostgreSQL (see SE-PosgreSQL), MySQL and
commercial DBMS, but we hope our approach is much more comprehensive.
However item-by-item consideration needs to be given to the features for
merging. For example, Trace API has been in use for years already, and
is quite stable.
Extensions for using it as the audit trail tool were simple and should
not cause problems. RBAC rework (e.g. access checking for GENERATORS and
DDL operations, cumulative force of roles assigned to the user) can be
merged in a relatively straightforward fashion. Things related to
cryptography and row-level security obviously need more work and
architectural review before they can be merged into Firebird.
Other
~~~~
There are also NBACKUP stabilization changes and Trace API feature,
which in my opinion can make their way into Firebird in 2.5 time frame,
subject to Roman Simakov (or somebody else) availability to perform the
merge.
Additionally we have designed “External Engine sandboxes” feature, using
the same extensions as XNET/INET communication mechanism for debugger to
communicate with ESP running in separate processes, but this work is
unlikely to progress further in the nearest future. No code was written
to implement this design to the best of my knowledge.
All features have detailed specs, but in Russian only. Unfortunately,
not all our specialists and contractors are proficient in English.
Release notes describe all the features in still bad, but hopefully
comprehensible English.
Source code is included with the install packages. Internally, patches
are kept in merge-friendly form in an SVN branch growing from hand-made
Firebird baseline (currently based on two-month-old Firebird HEAD +
patches).
We hope that working implementation of some of the features targeted for
Firebird 3.0 release can make it become available sooner.
Thanks and Best Regards,
—
Nikolay Samofatov, MBA
Red Soft International