[dais-wg] Updates Based on DAIS Factory Results

[Norman Paton]

I hope that the proposal as made doesn't open any cans of worms on the 
update semantics front, although there are, of course, lots of such cans 
to be avoided!
 
The proposal doesn't update the result sets themselves, but rather 
allows the result sets to be used as input parameters to updates over 
existing databases.  As such, the insert and delete operations described 
in the proposal only read from the result sets, while making changes to 
an existing database that need not be the one from which the result set 
was derived.

I note that the model of database update is not one that seeks to 
propagate changes to a result set back to their original source, as that 
also might be considered to be a can of worms!

I hope I have interpreted your question correctly ... it's just that the 
proposal seems to have avoided the specific issue raised.

Norman


Malcolm Atkinson wrote:

>It would seem to me to be a very odd semantics that allowed update of a
>result set.  The result set may be incrementally instantiated much later
>as it is read - what would an update mean?
>
>Malcolm
> 
>
> >-----Original Message-----
> >From: owner-dais-wg at ggf.org [mailto:owner-dais-wg at ggf.org] On 
> >Behalf Of Norman Paton
> >Sent: 23 May 2005 14:31
> >To: dais-wg at ggf.org
> >Subject: [dais-wg] Updates Based on DAIS Factory Results
> >
> >
> >The DAIS specifications support Factory operations, which return 
> >identifiers for
> >the results of queries.  However, there is a lack of symmetry in the 
> >handling of
> >such results in the specs, in that their identifiers cannot 
> >currently be 
> >provided
> >as inputs to update operations.  This note comments on options for 
> >extending this
> >capability. 
> >
> >1. Relational
> >
> >In the relational model, data access and manipulation 
> >requests are directed
> >at data services using the SQLAccess operation.  Additional 
> >operations could
> >be defined on the relational data access service or on the 
> >SQLRowSet that
> >in some way push the contents of the row set to the 
> >relational data access
> >service.
> >
> >1.1 Insert
> >
> >The following operation could be defined:
> >
> >SQLAccess::Insert(TableName, FieldMapping, RowsetIdentifier) -> 
> >SQLExecuteResponse
> >
> >Given the name of a table, insert the tuples from the rowset into the 
> >given table.
> >
> >Faults:
> >- Unable to access Rowset.
> >
> >The semantics might most easily be assumed to be those of the 
> >existing 
> >SQL clause:
> >
> >insert into TableName [(FieldName1 [, FieldName2, ...])] SelectClause
> >
> >where the SelectClause is assumed to range over the tuples in the 
> >RowSet.  The
> >SQLExecuteResponse provides access to the SQLCommunicationsArea, and 
> >thus is able
> >to provide access to a wide range of error conditions.
> >
> >The FieldMapping would represent a list of pairs, associating 
> >each named 
> >field in
> >TableName with each of the fields in the SQLRowSetSchema; it could be 
> >optional if
> >the names in the two settings had a 1:1 mapping.
> >
> >
> >1.2 Delete
> >
> >The following operation could be defined:
> >
> >SQLAccess::Delete(TableName, FieldMapping, RowsetIdentifier) -> 
> >SQLExecuteResponse
> >
> >Given the name of a table, delete the tuples from the rowset from the 
> >given table.
> >
> >Faults:
> >- Unable to access Rowset.
> >
> >The semantics might most easily be assumed to be those of the 
> >existing 
> >SQL clause:
> >
> >delete from TableName WHERE <condition>
> >
> >where the condition is assumed to test for tuples that match those in 
> >the RowSet,
> >given the name mapping in FieldMapping.  The match should probably 
> >involve equality
> >on all attributes, but matching only on key is also an option. 
> >SQLExecuteResponse
> >provides access to the SQLCommunicationsArea, and thus is able to 
> >provide access
> >to a wide range of error conditions.
> >
> >The FieldMapping would represent a list of pairs, associating 
> >each named 
> >field in
> >TableName with each of the fields in the SQLRowSetSchema; it could be 
> >optional if
> >the names in the two settings had a 1:1 mapping.
> >
> >
> >2. XML
> >
> >Unlike the WS-DAIR specification, the WS-DAIX spec contains top-level 
> >update operations,
> >namely:
> >
> >XMLCollectionAccess::AddDocuments([Name, Collection, Data]) -> 
> >ResponseDocument
> >XMLCollectionAccess::RemoveDocuments([Name], Collection) -> 
> >ResponseDocument
> >XMLCollectionAccess::BulkLoad([Collections],[Name, 
> >Collection, Data]) -> 
> >ResponseDocument
> >
> >Where the above operations take Data as a parameter (for 
> >insertion only 
> >- deletes are
> >by document name, which seems more natural than by document 
> >matching), 
> >one could
> >envisage variants in which an XMLSequenceIdentifier is passed as a 
> >parameter.
> >
> >
> >Anyway, these are some initial thoughts on how the named 
> >results of DAIS 
> >factory operations
> >might be able to be used as inputs to other DAIS operations; comments 
> >invited. 
> >
> >Norman
> >
> >
> >
>  
>