Breaking out forum topic 314 into separate posts for each proposed Op.

Update

The update op is used to modify existing recs on the Haystack Server.

Request: a grid of records containing all recs to be updated on the server. Prior to performing an Update, the client should do a Read to ensure it has the latest version of the rec to be modified.

Response: order consistent grid containing all recs that were updated on the server. An "err" column should also be added so any rows that encountered an error during the update can report such error.

Example:

Here is an example which posts some updated recs to the server:

// request
ver:"2.0"
id,dis,equip,equipRef,his,kind,point,site,siteRef,vav
@1234,"Site 1234",,,,,,,,
@2345,"Equip 2345",M,,,,,,@1234,M
@3456,"Point 3456",,@2345,M,"Number",M,,@1234,

// response
ver:"2.0"
id,dis,equip,equipRef,his,hsid,kind,point,site,siteRef,vav
@1234,"Site 1234",,,,@1234,,,,,
@2345,"Equip 2345",equip,,,@1234,,,,@4321,M
@3456,"Point 3456",,@2345,M,@3456,"Number",M,,@1234,

Questions:

1. Should we add to the standard the concept of versioning, or should this be left as a server specific implementation? My opinion is that it should be left as a server specific implementation.
2. Per Brian's suggestions with the proposed Create Op, should all operations complete or fail atomically?

Shawn,

1. Agree - server-specific.
2. I tend to agree that atomicity is important. This is straightforward enough in a single-entity update, but might get complicated with multi-entity updates? Regards, Mark