[fdo-internals] Connection state and commands

[Greg Boone]

Se inline...

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Mateusz
Loskot
Sent: Friday, February 16, 2007 3:11 PM
To: fdo-internals
Subject: [fdo-internals] Connection state and commands

Hi,

Is there any general rule about what connection state is required
for what command or it is provider specific?

For example:

- FdoConnectionState_Open is required for commands like:

SQLCommand or Select Command
[GB] Yes. This is the rule.

- FdoConnectionState_Pending is a minimum requirement for commands like

ListDataStores
CreateDataStore
etc.
[GB] Yes, this is also the typically state at which point these commands
are run.

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. 

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.


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. 

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