[fdo-internals] Connection state and commands

[Greg Boone]

See [GB2] below...

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Mateusz
Loskot
Sent: Thursday, February 22, 2007 10:46 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] Connection state and commands

Greg Boone wrote:
Mateusz Loskot wrote:
>> Now, is this assumed, across all FDO providers, that ListDataStores
>> or CreateDataStore will only work with connection of state open?
>
> [GB] No. These commands should at  minimum be executable with a
> connection state of pending

OK.

>> Perhaps, I a provider developer has liberty to set a requirement
>> that if connection is open to a particular datastore,
>> it's not possile to call commands operating on datastores:
>> CreateDataStore, DestroyDataStore, ListDataStores,
>> but pending connection is required?
>
> [GB] You could do this, but that may be too restrictive. There may be
> some unforeseen use case where a user would wish to execute these
> commands which in an Open state. However, I would argue that we should
> be consistent across all RDBMS providers and enforce a general rule. 

OK. I understand the general rule is to support these commands under
both connection states: open or pending

>> Similarly, if connection state == pending it shouldn't be possible to
>> create any commands other than operating on datastores.
>
> [GB] Yes, typically only datastore commands should be available at
this
> time.

OK.

>> As I see in available providers, it's handled differently:
>> - one provider validates connection state before creating commands
>> - another doesn't check the state at all
>
> [GB] I would argue that providers should always check their internal
> state before creating commands. To do otherwise sounds like a defect. 

If providers should not check the minimum required state for a
particular command, then how to communicate about the real problem?

For example:

1. Connection is pending
2. One requests for SQLCommand
3. Connection object constructs the command and returns it to the user
4. User calls SQLCommand::Execute()
5. Command fails because of.... what?

In FDO, where we have quite a liberty about defining of what is a
datastore and what Open() connection to a datastore means,
issuing meaningful error to a user is almost impossible.

IMHO, providers should provide details about the real reason:
- connection is not open yet to issue the requested command

Am I wrong or may be I've missed some details?
[GB2] I agree. I would advise that each provider determine its state and
throw an appropriate user-friendly error from
FdoIConnection::CreateCommand where appropriate. It is not a good idea
to allow a user to create a command if it cannot be executed. 

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals