| Subject | Re: [Firebird-Architect] for discussion Transient Data Set |
|---|---|
| Author | Dmitry Yemanov |
| Post date | 2005-01-14T13:20:34Z |
"Ann W. Harrison" <aharrison@...> wrote:
1) Forget about returning datasets from multiple row updates (my proposal)
2) Forget about single network roundtrip (your proposal)
Probably, we could implement both, but it would require two different extentions (e.g. both RETURNING and YIELDING) for the affected DML, which looks like a mess.
Another issue is namespaces. How should a connectivity library generate a tds name for a particular INSERT to ensure this name becomes unique and won't generate an exception? Or user should care about this himself explicitly without any chance for a library to do some useful things automagically?
Also, I'm pretty sure that an ability to retrieve a single list of values is much more expected by our users than multiple row results. This is what people talk about. So those who may need the multiple results could wrap their INSERT into an EXECUTE BLOCK statement returning required data.
And finally. The affected rows can be collected by the engine either row-by-row (i.e. along with the actual DML execution) or via an extra select performed at the end. The former approach may return unpredictable (read: wrong) results when row-level triggers touch the same table. E.g. update of the second row causes indirect modification of the first one. What should be returned in this case? If the values to be returned are collected with an extra select statement, then I don't see what it gives us at all.
To summarize my opinion: the suggested TDS feature is not very useful for I/U/D statements. And I still think that multiple row results shouldn't be returned from I/U/D at all.
Dmitry
>Let's get back to the original talks about RETURNING. It's required for two things: (a) return underlying table data after a DML operation and (b) do it in a single network roundtrip with a base DML. The latter requirement is very important. But it seems it cannot be done for multiple row updates. So, we have two options:
> where the <col list> is list of names that match a subset of the column
> names in <table>. If no <col list> is specified, columns for
> <tds_name> would have the same name and datatypes as the columns in
> <table>, including columns not listed in the insert. If <col list> is
> specified, columns in the temporary data set will have the same data
> type as the column in <table> that has the same name.
>
> [snip]
1) Forget about returning datasets from multiple row updates (my proposal)
2) Forget about single network roundtrip (your proposal)
Probably, we could implement both, but it would require two different extentions (e.g. both RETURNING and YIELDING) for the affected DML, which looks like a mess.
Another issue is namespaces. How should a connectivity library generate a tds name for a particular INSERT to ensure this name becomes unique and won't generate an exception? Or user should care about this himself explicitly without any chance for a library to do some useful things automagically?
Also, I'm pretty sure that an ability to retrieve a single list of values is much more expected by our users than multiple row results. This is what people talk about. So those who may need the multiple results could wrap their INSERT into an EXECUTE BLOCK statement returning required data.
And finally. The affected rows can be collected by the engine either row-by-row (i.e. along with the actual DML execution) or via an extra select performed at the end. The former approach may return unpredictable (read: wrong) results when row-level triggers touch the same table. E.g. update of the second row causes indirect modification of the first one. What should be returned in this case? If the values to be returned are collected with an extra select statement, then I don't see what it gives us at all.
To summarize my opinion: the suggested TDS feature is not very useful for I/U/D statements. And I still think that multiple row results shouldn't be returned from I/U/D at all.
Dmitry