On 08/02/2007 02:27 AM, lacakus wrote:

> If not acceptable, then use Oracle's "@" ... and then accept also
> Oracles :
>
> CREATE DATABASE LINK dblink
> [ CONNECT TO
> { CURRENT_USER
> | user IDENTIFIED BY password
> [ dblink_authentication ]
> }
> | dblink_authentication
> ]
> [ USING 'connect_string' ] ;
>
> or Firbird modified (like CREATE DATABASE ... does not introduce
> new "DATA SOURCE" and "PROVIDER" keywords):
>
> DECLARE EXTERNAL DATABASE dblink
> {CONNECT | USING} 'connect_string'
> [USER 'username' [PASSWORD 'password'] | CURRENT_USER]
>
> Keep it as simple as posible.

Hi All,

First, is there a written set of goals/requirements that
Vlad's implementation is attempting to address? This isn't to
detract from his proposal, I'm just trying to understand the
*big picture* here. Regarding distributed (heterogeneous?)
queries, distributed DML and distributed tx's, what do FB
users want short term and long term (in a few+ years)?
Knowing this could help... ;-)

Second, the "DB link" approach has some advantages over making
users define parallel table definitions and keep them in sync.
Instead, let the local server get the result set descriptions
at query time and allow (privileged) users to create DB links.
A DB link specifies how to connect and authenticate a local
user to a remote database server, when necessary. In this
case, the table@dblink syntax seems the most obvious and
familiar. Although, that's just my personal preference
(perhaps due to decades of unix and Oracle use). ;)

Also, the Oracle "USING 'connect_string'" clause allows one to
specify, for example, protocol, address, port, etc. for a
given DB link. So, it's possible to define multiple DB links
to the same remote database server, each using a different
path/protocol/encryption/carrier/whatever.

A similar capability might be useful in FB for, say, app.
failover in an embedded M2M app. For example, when the primary
network fails and the app. needs to temporarily failover to a
redundant (perhaps higher latency) secondary path to the
remote server:
select * from targets@hq_T1;
select * from targets@hq_satellite;

A further simplification, for the user at least, might be to
allow the DB link creator to specify a prioritized list of
connect strings. Then, have the local server "open" the "best"
connection it can, at query time. This seems cleaner, but it
should probably wait for phase 2+. :)

Not everyone's cup of tea, but multiple links can come in very
handy in certain situations.

Finally, who will own and what users can use DB links
(datasources)? There are various flavors of Oracle DB links
available, not obvious in the above syntax: global, public,
shared, and private. However, I'm not sure all these would be
necessary for FB.

A "simpler" alternative might be to support grant/revoke
statements on each DB link, to grant/revoke access to a set of
users and roles. This would be particularly helpful with a
shared "fixed user" DB link, that specifies a fixed remote
USER name and PASSWORD. Here's a hypothetical example:

CREATE DATABASE LINK hq_T1
CONNECT TO tracker42 PASSWORD superSecret
USING 'tcp://hq.example.com:34567'; -- or whatever

GRANT SELECT ON hq_T1 TO bob, carol, ted, alice;


...Something to consider, at least. :)

Regards,
Fred P.