Roman,

Le 25-juil.-05 à 21:28, Roman Rokytskyy a écrit :

>> Database backup / restore would be just fine attaching to the DB
>> first (restore is just a special case of create_database).
>
> How does the create database fit your architecture - you cannot
> connect to something that does not exist.

You don't connect to a database to create it. You call something like
isc_create_database(), passing it a connection string which while
traversing the (maybe multiple) y-valves will end up in the hands of
a provider (the last provider on the chain is an engine) that will
try to create your database. It works this way already.

> In fact you have a shortcut
> in your architecture, some kind of a flag - "if database is not there,
> create it".

No Roman there is no shortcut here. Or maybe we didn't understood
each other. Which is possible.
Creating a database does not imply first connecting to it. It just
implies calling an entry point with a connection string as parameter,
which y-valves to y-valves will finally be executed by some engine (a
provider among others). Restoring a database could be the same,
passing a connection string for the database to be restore (which
might not exist at this time and a connection string to refer to the
database backup file(s)). The provider/engine able to handle the
request will proceed.

> So, in fact the answer to the yet unknown question is one of the
> following:
>
> a) there is a single attachment to the database and all service
> operations are accessible via SQL;
>
> b) there is an attachment to the database where DDL and DML commands
> can be issued and there is an attachment to the database where all
> maintanence commands can be issued.

I don't think there is a need for two different attachments to
database, wether or not all service operations are accessible via
SQL. One single attachment kind to the database could very well be
used for DDL / DML and for 'administrative tasks' through other API
entry points. There might be specific advantages to having a second
kind of database attachment where you can't issue DDL/DML. I don't
immediately see why, but of course why not. I have to agree with you
that the services API ressemble a bit to that with a big difference
though: using the services API, you first must get a service handle
(a service attachment), something which is database independent. Then
using that handle you can ask for services, which, of course are
database related (for most). This intermediate step is not required
and shouldn't exist to clarify.

>> In the current architecture you can't know (or you shouldn't know or
>> have to know) *which* engine will serve your database attachment
>> until you will ask for attachment of that database. For this
>> database, it could be a 32 bits engine of version 2.x. For this
>> database, it could be a 64 bits engine. For this other one it could
>> be a version x.y engine. To what 'engine' do you want to attach in
>> order to make administrative work against this or that database,
>> since you can't know at first what engine will serve your requests
>> for that database ?
>>
>
> I don't. There is a Y-valve to which I attach. If I understand it
> correctly, in Vulcan architecture application does not attach to the
> provider (="engine" in your terms) - it always goes through some
> client library. So, what I expect from that library, is to forward my
> maintanence request to the suitable provider.

That's exactly what I wrote, so I think we understand each other
here, with slightly different wording.

>> To talk about gfix things, who knows how to change the setting 'XYZ'
>> of your database 'ABC' ? Answer: the engine that will in the end
>> handle your request for changing 'XYZ' setting on database 'ABC'.
>> What engine is this ? Answer: you'll know when you'll attach that
>> database.
>>
>
> Not me, the Y-valve will know. I do not want to know that there are
> multiple providers behind my API. I do not care - I have my ISC API
> and I tell it to do the job. And it either succeeds or fails.

We're still synced together here, I think.

> So, the main question is whether we want to choose a) or we want to
> choose b). When we choose a) it means that provider has to know all
> possible service SQL statements. You want to add new one, you have to
> modify the SQL interpreter.

I know today updating the SQL interpreter is not a fun job, but what
issue would there be to have to extend it each time some new service
facility is added ?

> If we choose b) and use similar API that
> it is now, we have a possibility to have "services-plugins" without
> changing the provider.

I am not sure about that Roman. What kind of service plugins could be
added that wouldn't require the knowledge that only an engine-
provider has about a database ? Oh yes I suppose you consider the
plugins at the engine-provider level. Then it should be possible to
extend the SQL interpreter through some plugins too.

--
Olivier Mascia