Getting structured data using GetData and IDataReader

[Plausible Indirection]

Somewhat theoretical question; so, if that kind of thing doesn't
interest you, quit reading.

Suppose you have data in one or more of the SQL3 types, row or
collection, where each entity could contain other entities. Row types
can contain other row types or an element of a row could be a
collection; it is possible to define a collection of rows, etc.

I'm looking at the GetData method of IDataRecord which returns an
IDataReader. The description for GetData tells me that this method
"gets an IDataReader to be used when the field points to more remote
structured data." This seems tailor made for this kind of task.

But...

You are getting a datareader and it seems that no other operations are
allowed on the database while a datareader is open. Would that
include the Read() and GetX() methods of other datareaders? If yes,
that would mean that you would have to get all that you wanted out of
the deepest nested record and close it before calling a Read or a GetX
on any of the parent readers. That would be doable, but could be
inconvenient. If no, what about thread safety? Would you expect to
be able to pass a non-root node datareader off to another thread for
further processing?

What exactly would the Read method mean if you performed it on a
nested datareader? Would it be like you were accessing the next item
in a collection rather than the next row in a database table?

I think it would have been better to have the GetData method return an
IDataRecord. Then you could think of the returned value as just a
collection of data and not have to think of it as something that
interacted with the database.

Anyone have any thoughts on the matter?

-Chris

 

[Plausible Indirection]

Packet loss between brain and keyboard.

If the Read() and GetX() methods are considered to be database
accesses (on the connection), then the spec seems to be internally
flawed. You couldn't access the complex type data using a reader
without closing the parent reader and that would make getting the next
row from the parent reader most inconvenient. So, you'd have to
assume that they aren't and that the spec writers, when they wrote
that the connection was busy with the first reader, either didn't
consider how the child reader was ever going to be used or that they
thought of the child readers as existing only as part of the parent
reader.