Roman Rokytskyy wrote:

>> The system result sets are what drive basically all database tools. If
>> the goal is to to make external tables appear transparent to the client,
>> there is no reasonable alternative to properly managing the system
>> result sets.
>>
>
> The system result sets that you are talking about are virtual in case of
> Jaybird. That means that we query the database for all needed bits and
> bytes, and then construct an object that implements the ResultSet
> interface and gives the needed data to the client. Sometimes we simply
> copy data from the result set, but sometimes we have to generate data.
>

Yup. Anyone can do anything. The question is architectural: Does the
new feature fit the architecture or does it introduce a whole set of new
crocky set of rules that upper layers had to deal with.

In this case, Vlad is trying to implement a feature on the cheap that
doesn't quite work. Rather than designing it to work with the existing
architecture *or* proposing an alternative architecture that handles
both cases consistently, he is suggesting that we ignore architecture
and pass the problem to client(s). Yes, it can be done. Should it be
done? Not my call. Will it lead to more problems than solutions?
Probably yes.

A good proposal solves all problems. Solving a few problems leaving the
others unresolved is the hallmark of a bad design.

Transparent access to remote tables is a very good capability, indeed.
But it has to work and it has to be transparent. The problems are well
understood, as are the solutions. But solutions are not simple, and
require serious consideration of trade-offs.

I suggest that folks consider a design in depth that addresses all of
the problems before a go / no-got decision is made. The current
proposal is a little on the thin side (at least in my humble opinion).

>
>> I'm sorry if this is inconvenient, but there are reasons that external
>> tables haven't been implemented over the 22 years since gds/Galaxy
>> version 1.
>>
>> I'm not saying that it isn't a good idea or can't be done, but a proper
>> implementation is quite a bit of work and I'm afraid there are no shortcuts.
>>
>
> Are you talking about the proper system tables in the Firebird that
> would show the external tables?
>
>
>>> If we implement catalogs (e.g. external data source is a catalog) and
>>> engine provides a possibility to access the needed information in the
>>> remote database via system tables or selectable system procedures (in
>>> other words the parser would somehow distinguish the query involving
>>> catalog name), that would work. For sure, we (driver developers) will
>>> have to update drivers to support it, but that's ok.
>>>
>>>
>> If you say so, I guess, but that sounds to me like hand waving to avoid
>> solving the problem.
>>
>
> Here I was talking about the technical possibility to implement it this
> way. I don't like it, I'd prefer normal system tables, but I can hide
> all details behind the ResultSet interface implementation.
>
> Roman
>
>
>
> Yahoo! Groups Links
>
>
>
>