Fuhwei, I don't think we have any requirements on SDO here. This function is implemented today -- we're just trying to find a natural place for it to live.
On 8/7/06, Fuhwei Lwo <[EMAIL PROTECTED]> wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
