Brent,
I think it would help if you could describe the scenario from the user's
perspective. What are they trying to accomplish?
--Kevin
Fuhwei Lwo 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]
