[fdo-internals] Connection state and commands

[Mateusz Loskot]

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?

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net