El 30/01/10 08:24, Sergi Vladykin escribió:
>> If H2 instead of failing in advance when don't understand a sentence (in
>> pass-t mode) just allow the other database handle the sentence for and
>> act in regard of remote db exceptions or results, many things would work.
>> In case some operation don't fill the conditions needed on H2 for
>> handling such situation or results , at the end they will fail in the
>> same way they fail now - so no loss.
>>
> How h2 will decide to which linked db send query if it can't even parse it?
Good point, maybe a relaxed parse with the only purpose to discover the
target table on remote db, but this don't sound promising.
> Why it should parse the query at all if this query is
> targeted to another db? I think the right solution is to use stored
> procedures returning ResultSet. But to do it more convenient I think
> it is possible to add to h2 new db object DBLINK with syntax like
> CREATE DBLINK dblink_to_oracle (driver, url, user, password);
> and function like
> QUERY_DBLINK( dblink_to_oracle,
> SELECT xxx FROM some_oracle_table
> WHERE yyy = ?
> CONNECT BY PRIOR a = b
> )
> which can be used in more complex queries as function table. And the
> query inside this function will not be parsed, only "?" should be
> found to set parameters and execute it on this dblink. I think you
> want something like this.
YES,yes,YES - wonderful idea ! Imagine all possible uses for something
like this.
In a previous post I say to use a generalization of the concept :
LINKED_TABLE -> LINKED_SCHEMA -> LINKED_QUERY -> LINKED_DB (or
federated connection or DBLINK that sound very intuitive).
I know that QUERY_DBLINK() function it's much more easy to implement
that another new database object as LINKED_QUERY,
but may be for the future , a persistent db object LINKED_QUERY as it be
a remote view over a DBLINK or LINKEDB would be nice and consistent with
the current features.
DBLINK and QUERY_DBLIINK() as you suggest inherently achieves maintain
its usefulness as a tool for data extraction mixed querying, as in:
CREATE TABLE localtable AS ( SELECT * FROM QUERY_DBLINK(...)) ;
INSERT INTO localtable ( SELECT * FROM QUERY_DBLINK(...) ) ;
SELECT L.*, R.* FROM localtable as L , LINKED_QUERY() as R where
R.id = L.id
With this implementation even query data from mixing local and linked
tables will be posible, because at h2 parsing they only have to check
the syntax of an UDF/SP call.
> But this will not be a one day work and I'm not sure if Thomas will approve
> this feature.
I understand that clearly and I hope that Thomas shares our opinion that
this generalization of objects and features that are already included in
H2,
virtually eliminates all restrictions on the use of an external data
source within the context of a session of h2.
regards,
Dario
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
