firebird/firebird-mirror
firebird/firebird-mirror
8
0
Fork 1
mirror of https://github.com/FirebirdSQL/firebird.git synced 2025-02-02 10:40:38 +01:00
Code Issues

Reflected API changes in beta1

Browse Source
This commit is contained in:
alexpeshkoff 2014-11-13 10:30:41 +00:00
parent e055cea86d
commit 4778665a44
3 changed files with 45 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
doc/README.interfaces.html
View File

@ -3,11 +3,12 @@
<HEAD>
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>
<META NAME="GENERATOR" CONTENT="OpenOffice 4.0.1 (Unix)">
<META NAME="GENERATOR" CONTENT="OpenOffice 4.1.1 (Unix)">
<META NAME="AUTHOR" CONTENT="alex ">
<META NAME="CREATED" CONTENT="20130531;10003100">
<META NAME="CHANGEDBY" CONTENT="Alex Peshkoff">
<META NAME="CHANGED" CONTENT="20131106;14262300">
<META NAME="CHANGED" CONTENT="20141113;13173600">
<META NAME="CHANGEDBY" CONTENT="Alex Peshkoff">
<STYLE TYPE="text/css">
<!--
@page { size: 8.5in 11in; margin: 0.79in }
@ -47,11 +48,11 @@ time by BLR (binary language representation) of that request. But SQL
operator does not contain description of message format and therefore
decision was taken &ndash; surround each message with short BLR
sequence (hard to call that program) describing it's format. For a
reason they had decided to follow that rule too exactly &ndash; and
each fetch of data from server now required sending BLR for it, i.e.
formatting BLR was sent not only at SQL compile time. The reason for
such strange at the first glance solution was presence of one more
layer on top of that messages based API - familiar to you SQLDA
reason they had decided to follow that rule too exactly &ndash; it
was possible to send modified BLR for each fetch of data from server,
i.e. formatting BLR was sent not only at SQL compile time. The reason
for such strange at the first glance solution was presence of one
more layer on top of that messages based API - familiar to you SQLDA
(XSQLDA). Rather obvious that manually accompanying each SQL
statement with BLR is not efficient programming style, therefore
SQLDA was invented. But it encapsulates in same object both location
@ -121,16 +122,17 @@ IStatus it's better to have simpler way to destroy it, i.e. dispose()
function.</FONT></P>
<P STYLE="margin-bottom: 0in"><BR>
</P>
<P STYLE="margin-bottom: 0in"><FONT COLOR="#ff0000"><FONT SIZE=4>Careful!</FONT></FONT><FONT SIZE=4>
An ability to upgrade interface version places one important limit on
implementation of interfaces: it should not contain virtual functions
(including virtual destructor) except those defined in interface
definition. This is because interface upgrade process modifies table
of virtual functions, and for successful upgrade, number of functions
in interface implementation should exactly match one in its
definition. Pointer to functions, missing in interface definition but
added in its implementation, may be </FONT><FONT COLOR="#ff0000"><FONT SIZE=4>overwritten</FONT></FONT><FONT SIZE=4>
with a pointer to function used to upgrade interface.</FONT></P>
<P STYLE="margin-bottom: 0in"><FONT COLOR="#ff0000"><FONT SIZE=4>Careful!</FONT></FONT>
<FONT SIZE=4>An ability to upgrade interface version places one
important limit on implementation of interfaces: it should not
contain virtual functions (including virtual destructor) except those
defined in interface definition. This is because interface upgrade
process modifies table of virtual functions, and for successful
upgrade, number of functions in interface implementation should
exactly match one in its definition. Pointer to functions, missing in
interface definition but added in its implementation, may be
</FONT><FONT COLOR="#ff0000"><FONT SIZE=4>overwritten</FONT></FONT>
<FONT SIZE=4>with a pointer to function used to upgrade interface.</FONT></P>
<P STYLE="margin-bottom: 0in"><BR>
</P>
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>Discussing in details all

25
doc/README.plugins.html
View File

@ -3,9 +3,10 @@
<HEAD>
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>
<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.4.1 (Unix)">
<META NAME="GENERATOR" CONTENT="OpenOffice 4.1.1 (Unix)">
<META NAME="CREATED" CONTENT="20130417;16154700">
<META NAME="CHANGED" CONTENT="20130621;20102600">
<META NAME="CHANGEDBY" CONTENT="Alex Peshkoff">
<META NAME="CHANGED" CONTENT="20141113;13254700">
<STYLE TYPE="text/css">
<!--
@page { margin: 0.79in }
@ -91,18 +92,22 @@ set of plugin types:</FONT></P>
special Firebird interfaces (see README.interfaces about interfaces
in Firebird). All plugin-specific interfaces are reference counted,
i.e. have explicitly controlled lifetime. Interfaces are declared in
Plugin.h include file. There is a simple example of writing plugin
module &ndash; DbCrypt_example. It does not perform any actual
Interfaces.h include file. There is a simple example of writing
plugin module &ndash; DbCrypt_example. It does not perform any actual
encryption &ndash; just a sample of how to write plugin. Complete
instruction of how to write plugins is out of this document's scope.
Here is provided a short list of plugin features:</FONT></P>
<UL>
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>plugin may be written
using any language, supporting pure virtual interfaces (you will
need to rewrite interfaces declarations for your language if they
are missing);</FONT></P>
using any language, supporting function pointers in a
structure/record (or at least arrays of function pointers);</FONT></P>
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>currently interfaces
description is available only for C++ language, at release time
plain-C and delphi/fpc descriptions will be present (you will need
to write your interfaces declarations generator for your language if
you need something else);</FONT></P>
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>like with UDFs you
are free to add any reasonable code yo your plugin, but pay
are free to add any reasonable code to your plugin, but pay
attention to word &ldquo;reasonable&rdquo; - asking a question from
plugin at server's console is hardly good idea;</FONT></P>
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>it's OK to use
@ -272,8 +277,10 @@ connect to pre-FB3 servers. (Yes &ndash; it still transfers almost
plain passwords over the wire. Compatibility...) On server it works
with security database from FB 2.5, and should be avoided except
cases when you understand well what are you doing. To use Legacy_Auth
on server you should also disable network traffic encryption in
on server you should set lower level of network traffic encryption in
firebird.conf:</FONT></P>
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>WireCrypt = Enabled</I></FONT></P>
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>or in the worst case:</FONT></P>
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>WireCrypt = Disabled</I></FONT></P>
<P STYLE="margin-bottom: 0in"><BR>
</P>

18
doc/README.providers.html
View File

@ -3,9 +3,10 @@
<HEAD>
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>
<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.4.1 (Unix)">
<META NAME="GENERATOR" CONTENT="OpenOffice 4.1.1 (Unix)">
<META NAME="CREATED" CONTENT="0;0">
<META NAME="CHANGED" CONTENT="20130611;16182500">
<META NAME="CHANGEDBY" CONTENT="Alex Peshkoff">
<META NAME="CHANGED" CONTENT="20141113;13283500">
<STYLE TYPE="text/css">
<!--
@page { margin: 0.79in }
@ -115,8 +116,9 @@ name or whatever else you choose). In this sample when database name
used caching provider accepts such connection and invokes YValve once
again with traditional database name </SPAN><I>RemoteHost:dbname</I><SPAN STYLE="font-style: normal">.
But when user later performs any call to his database caching
provider gets control on it before </SPAN><SPAN STYLE="font-style: normal"><B>Remote</B></SPAN><SPAN STYLE="font-style: normal">
one and for locally cached table can avoid calls to remote server.</SPAN></FONT></P>
provider gets control on it before </SPAN><SPAN STYLE="font-style: normal"><B>Remote</B></SPAN>
<SPAN STYLE="font-style: normal">one and for locally cached table can
avoid calls to remote server.</SPAN></FONT></P>
<P STYLE="text-indent: 0.39in; margin-bottom: 0in; font-style: normal">
<FONT SIZE=4>Using chaining one can implement a lot of other useful
things like database replication without need in triggers - just
@ -158,7 +160,8 @@ problem migrating to Firebird 3?</FONT></P>
<P STYLE="text-indent: 0.39in; margin-bottom: 0in; font-style: normal">
<FONT SIZE=4>A. Definitely no problems. Old API is supported for
backward compatibility in Firebird 3 and will be supported in future
versions as long as people need it.</FONT></P>
versions as long as people need it. Moreover, since Firebird 3 one
can access from XSQLDA API records longer than 64Kbytes.</FONT></P>
<P STYLE="text-indent: 0.39in; margin-bottom: 0in; font-style: normal">
<FONT SIZE=4>Q. And what about performance when using old API?</FONT></P>
<P STYLE="text-indent: 0.39in; margin-bottom: 0in; font-style: normal">
@ -171,8 +174,7 @@ execute SQL operator and fetch data from it. But SQLDA and related to
it data moves has never been the most fast place of functional API,
it was one the reasons to have new API and logic between new and old
API does not add much to that old overhead.</FONT></P>
<P STYLE="text-indent: 0.39in; margin-bottom: 0in; font-style: normal">
<BR>
<P STYLE="text-indent: 0.39in; margin-bottom: 0in"><BR>
</P>
</BODY>
</HTML>
</HTML>