[fdo-internals] Connection state and commands
greg.boone at autodesk.com
Thu Feb 22 15:21:52 EST 2007
See [GB2] below...
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Mateusz
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
>> 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
>> 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?
[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.
fdo-internals mailing list
fdo-internals at lists.osgeo.org
More information about the fdo-internals