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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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]
