Brent, I am sorry I still don't understand what your SDO requirement is. You pretty much can accomplish your Step #1 and #3 by using the exising SDO APIs. The only SDO API we are missing here I can think of is to associate a data graph object with a root data object. Fuhwei
Brent Daniel <[EMAIL PROTECTED]> wrote: Fuhwei, In this scenario we will not retrieve any metadata from the database, so you can remove step number two. The scenario would be: 1) If SDO Types have not been provided, create them using information from the user-provided config. 2) Create an empty DataGraph using SDOUtil.createDataGraph() 3) Create a root object in that DataGraph using either the provided or das-created Types. Brent On 8/4/06, Fuhwei Lwo wrote: > Hi Brent, > > Is this your usage scenario? > > 1. Create an empty data graph object without database access > 2. Retrieve the metadata from the database > 3. Create service data objects (SDO) based on the metadata > 4. Associate the data object tree with the data graph created in #1 > > Fuhwei Lwo > > Brent Daniel wrote: 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 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 > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
