Paul,
 I see your point about the scoping -- but, in some sense, that's
what we intend to provide here -- a DataGraph that represents the
reults of a query that returns no results. When we aren't given SDO
types, the structure of a DataGraph is determined by a query.

I guess, to summarize, we have a few choices:

1) Have a helper method, either on some GraphHelper class or on DAS to
return an empty graph based on user-provided SDO types.

2) Have the helper from (1), and also have the ability to execute an
"empty" command. The drawback here is that we have two different ways
to accomplish the same thing.

3) Have only the ability to execute an "empty" command --
user-provided SDO types will be used if they're there.

Number three seems the cleanest to me from a code standpoint. I
wouldn't be opposed to (1) either, as defining a ResultDescriptor per
Command seems like way too much work for the user (at that point why
not just generate types?)

Brent

On 8/4/06, Paul Golick <[EMAIL PROTECTED]> wrote:
On 03/08/06, Brent Daniel <[EMAIL PROTECTED]> wrote:
>
> 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.

It seems to me that it is most natural for an empty graph to be associated

with a DAS instance because the DAS instance is associated at its creation
with a connection and optional configuration information.

Associating an empty graph with a command would suggest that the empty
graph is not really empty but is like an empty result set from a single
query.

If the empty graph is to be populated with multiple subtrees that could
require multiple SQL insert statements when flushed to the database, the
correspondence with a single command is not very apparent.

Regards,
Paul Golick
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]

Reply via email to