Well, I'm using "DataGraph" very generally here to refer to providing a root DataObject with the appropriate set of SDO Types to a user based on information contained in the DAS. In practice the actual concept of a graph is hidden from users in the current rdb das implementation.
Brent On 8/4/06, Fuhwei Lwo <[EMAIL PROTECTED]> wrote:
Current SDO spec working group is discussing to make DataGraph a DataObject with predefined properties, changeSummary and modelType, in future version. This could mean you can treat DataGraph as regular DataObject if you like. Not sure this is what you are looking for. Regards, Fuhwei Lwo Brent Daniel <[EMAIL PROTECTED]> wrote: Hi Kelvin, I'm just trying to gain consensus on the programming model for the current relational DAS implementation. Now that I think about it, the ability to produce an empty graph is probably something that should apply to all DAS implementations, and should probably show up in the spec. We are creating the DataGraph using the SDOUtil function. In the empty graph case, we create the graph, create a root object, turn on logging, and then return the root. Brent On 8/4/06, kelvin goodson wrote: > Brent, > I'm not sure I have a full handle on your issue but I will say that I > think that the creation of an empty data graph seems like a natural > responsibility of a DAS. I'm afraid I haven't been following the DAS spec > efforts as closely as I'd like to, so I'm guessing that when you say the > "DAS interface" you mean the relational database DAS interface, yes? Or do > you mean a generic DAS interface? In either case I think a vanilla > createDataGraph() type operation would be appropriate, but I'm not sure how > general the version with the String command would be on a generic interface. > > Just a quick check, are you aware of the SDOUtil.createDataGraph() method > that we have to fill this gap? > > Regards, Kelvin. > > On 03/08/06, Brent Daniel wrote: > > > > We have a use case for the DAS that involves creating an empty graph > > without a database read. Kevin and I had talked about having a > > "GraphHelper" that provides this function, but I'm wondering if this > > should live somewhere else, like on the DAS interface. > > > > In the normal flow of operation, we receive all of the information we > > need to create a set of SDO Types from the metadata returned from a > > database query. For us to create an empty graph without a database > > read, we need to either have generated SDO types specified by the > > user, or we need the user to provide a ResultDescriptor (which > > overrides the metadata returned by the database.) > > > > Something like DAS.getEmptyGraph() would work well enough when the > > information is coming to us via a set of Types, but ResultDescriptor > > is scoped to Command. In that case, we would need something like > > DAS.getEmptyGraph(String commandName). Given that the user has to > > define a Command anyway, it might make more sense in this case to > > support some "no-op" type of Command and have everything go through > > the normal getCommand().execute() path. The case where SDO Types are > > specified could use the same path. > > > > I'm not sure which would be more intuitive, though I lean towards the > > "no-op" approach to keep the DAS interface cleaner.. any thoughts? > > > > Brent > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Best Regards > Kelvin Goodson > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
