[fdo-internals] Connection state and commands
mateusz at loskot.net
Thu Feb 22 10:45:41 EST 2007
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
>> 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
>> 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?
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?
More information about the fdo-internals