[dais-wg] Updates Based on DAIS Factory Results

[Malcolm Atkinson]

Norman,

Many thanks, I hadn't read the proposal and had misinterpreted the
purpose of the update. 

But, if the data is to be used in subsequent operations, e.g. as a
component of input to a subsequent operation, it is only necessary to
introduce a proper model for naming results and using names in
subsequent / other parts of requests - as I have advocated from the
beginning in OGSA-DAI - this is general and does allow multiple uses of
intermediate expressions / values that have been defined by early parts
of / requests.

I should clearly try to read the proposalbefore I comment further.

Malcolm


 >-----Original Message-----
 >From: Norman Paton [mailto:norm at cs.man.ac.uk] 
 >Sent: 31 May 2005 21:30
 >To: Malcolm Atkinson
 >Cc: dais-wg at ggf.org
 >Subject: Re: [dais-wg] Updates Based on DAIS Factory Results
 >
 >
 >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
 >> >
 >> >
 >> >
 >>  
 >>
 >
 >
 >
 >