Robbie, sorry for the slow response, some comments below ...
On 7/14/06, Robbie J Minshall <[EMAIL PROTECTED]> wrote:
These comments are with regard to comments on the AccessingDataObjectsUsingXPath sample. There are also some general questions about the roles of the end user of the DataObjects vrs DAS implementations regarding ChangeSummary logging. DATA GRAPH CREATION Yes there are three creation scenarios brought up here . . . # 1. Creation of a DataObject representing a DataGraph # 2. Creation of a DataObject # 3. Use of SDOUtil to create a DataGraph My current view is to keep this sample as close to the spec example as possible without being overly confusing. With this in mind I think it best if the sample just use a DataObject and provide comments explaining the confusion in the spec regarding #1.
+1 for that Then the sample should reference
a codeSnipet example which goes over #1 and #3. The alternatives seem to either vary too much from the specification example which this sample is supposed to mirror or become overly confusing. I mostly feel this way because the point of this particular sample was to demonstrate how to use xpath (though as you mention it is non standard xpath ) with SDO not the creation of DataGraphs. . . . thoughts ?
ok, so as I understand it the meaning of "codeSnippet" example here is that you have 3 kinds of examples, 1) mirroring as close as possible the examples in the 2.0.1 spec beginning at page 123; 2) code snippets harvested from all over the spec and 3) code samples from various publications, and the #1 and #3 variant of the xpath sample would be hived off to the code snippet set, with suitable comments to indicate the tricky issues. If so, then +1 for that too. With regard to the stages at which the samples are encountered this is
somewhat hard to control but I can certainly add some comments into the javadoc explaining that this sample delves into a somewhat murky area of the 2.0.1 specification. LACK OF A DAS > but we don't have a DAS here I would disagree here. A DAS is simply something that is tasked with creating DataObjects and/or defining the Types of those DataObjects. This is pretty much the extent which the SDO specification defines what a DAS is, or the state which a DataObject will be in upon creation. In this sample the XMLHelper is in fact providing a DAS implementation.
WHETHER OR NOT TO ENABLE LOGGING IN THE SAMPLE
It is not a big deal to enable logging though I think that there is some confusion here about what roles should invoke the begin/endLogging methods on ChangeSummary. If we put it in this sample users will think that they are responsible for setting the state of logging where at least the RDB DAS feels like it is their responsibility not the users. Are the users responsible for enabling and disabling ChangeSummary logging or is that to be up to the specific DAS implementations in use ? Perhaps the SDO specification should define what state it expects the ChangeSummary logging to be in for created DataObjects in order to avoid inconsistencies between DAS implementations.
ok, if you consider the XML helper to be a DAS, as you say there are no guidelines on behaviour for DASs, and I would guess a DAS designer would want to turn change logging on or off by default according to whether the data source lends itself to selective updating, so I think that this makes it natural for the XMLHelper to return graphs with Change Logging switched off In general the end user of DataObjects should not have to be aware of what
DAS created, or what DAS is going to persist the DataObject in order to determine the APIs to be used.
My guess is that sometimes a user will be aware of the DAS and sometimes not. Whatever the case the user can have expectations set by the specific environment they are working in; so if its close to the DAS, then the DAS sets the policy, if the DAS is abstracted away, then the abstracted environment sets the policy (which maywell be that change logging is always on), but I don't think we can envisage enough commanality between all DASs, exisiting or future, to take a stab at specifying the logging state for every DAS. Robbie
-- Best Regards Kelvin
