| Subject | Re: [ib-support] Again on the updatable views with triggers |
|---|---|
| Author | Jason Wharton |
| Post date | 2001-11-27T21:13:49Z |
Marco,
Ann Harrison and I have got a pretty clear picture in view. I think we will
be able to come up with a solution which will work quite well. What I have
communicated and what I think will work very well (which is largely what you
suggested) is as follows:
RowsAffected is what we are after but with views we need to think of it as
"rows operated upon" instead. In other words, when doing an update, we don't
care how the view trigger(s) implemented the actual updating of the view
record(s) but rather how many rows of the view were operated upon during the
update (or delete for that matter). With insert it is always just one.
This would rest upon an assumption which would need to be clearly
documented. Whenever making triggers on a view it is important that they
only affect the actual row of the view in the appropriate way expected. If
for whatever reason the triggers could not accomplish the desired affect
upon the view there should be an exception raised. If the triggers are wrong
and don't accomplish this then the fault be the programmers for breaking the
(what should be) rules.
Then, with this in place as such, we will have a system which delivers a
clear, consistent and uniform behavior for the RowsAffected property for
both tables and views. It puts the burden where it belongs and that is upon
the developer to properly implement the action in triggers on the view or
responsibility raise an exception when it fails to.
I believe this should be very straight forward to implement in the Firebird
code since RowsAffected for just plain tables is also the "rows operated
upon". Thus, it should be the same code and there is no need for it to
quantify the actual physical activities of the triggers to implement the
update to the view. Such is already the case with plain tables, why should
views be any different other than you are responsible to carry out the full
implementation of the updates.
I hope this restores some measure of confidence to this whole ordeal. And, I
really hope this is how it will be implemented because to me it appears as a
win-win-win situation for all involved. It also makes it totally unnecessary
to implement my -1 hack, which in retrospect was a horrible idea.
Marco, this is the way things are always going to appear at the "coal face".
(This is the part of a coal mine where the workers are struggling and
digging new territory under the earth. It is a very volatile and precarious
place to be.) With open source, many people are introduced to the "coal
face" and it rattles them a bit. You will get used to it, as do many of the
coal miners. (I lived for two years in a mining town.)
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
"Marco Lauria" <mslauria@...> wrote in message
news:5.0.2.1.2.20011127105631.03e35e90@......
Ann Harrison and I have got a pretty clear picture in view. I think we will
be able to come up with a solution which will work quite well. What I have
communicated and what I think will work very well (which is largely what you
suggested) is as follows:
RowsAffected is what we are after but with views we need to think of it as
"rows operated upon" instead. In other words, when doing an update, we don't
care how the view trigger(s) implemented the actual updating of the view
record(s) but rather how many rows of the view were operated upon during the
update (or delete for that matter). With insert it is always just one.
This would rest upon an assumption which would need to be clearly
documented. Whenever making triggers on a view it is important that they
only affect the actual row of the view in the appropriate way expected. If
for whatever reason the triggers could not accomplish the desired affect
upon the view there should be an exception raised. If the triggers are wrong
and don't accomplish this then the fault be the programmers for breaking the
(what should be) rules.
Then, with this in place as such, we will have a system which delivers a
clear, consistent and uniform behavior for the RowsAffected property for
both tables and views. It puts the burden where it belongs and that is upon
the developer to properly implement the action in triggers on the view or
responsibility raise an exception when it fails to.
I believe this should be very straight forward to implement in the Firebird
code since RowsAffected for just plain tables is also the "rows operated
upon". Thus, it should be the same code and there is no need for it to
quantify the actual physical activities of the triggers to implement the
update to the view. Such is already the case with plain tables, why should
views be any different other than you are responsible to carry out the full
implementation of the updates.
I hope this restores some measure of confidence to this whole ordeal. And, I
really hope this is how it will be implemented because to me it appears as a
win-win-win situation for all involved. It also makes it totally unnecessary
to implement my -1 hack, which in retrospect was a horrible idea.
Marco, this is the way things are always going to appear at the "coal face".
(This is the part of a coal mine where the workers are struggling and
digging new territory under the earth. It is a very volatile and precarious
place to be.) With open source, many people are introduced to the "coal
face" and it rattles them a bit. You will get used to it, as do many of the
coal miners. (I lived for two years in a mining town.)
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
"Marco Lauria" <mslauria@...> wrote in message
news:5.0.2.1.2.20011127105631.03e35e90@......
> At 22.25 26/11/2001 -0400, you wrote:at
> >"Marco Lauria" <mslauria@...> wrote in message
> >news:5.0.2.1.2.20011126184229.0377dc40@......
> >
> >No. If you knew the code, you would see that it's called several times,
> >least three: before, on the operation and after. Putting more checksthere
> >is like inviting a bug to appear. The API returns the number of directreally
> >operations done. It works for tables. The problem is that views don't
> >have I/O so when you only operate through triggers in non-updatableviews,
> >no op is returned, as triggers are never counted. And I already explainedof
> >that triggers may perform any number of operations.
> >I may consider (subject to other FB members' opinions) in the future
> >returning the sum of all I/O operations done by triggers in another item
> >the same API call, but I won't twist the server to do what you areengine.
> >suggesting, sorry.
> OK, so there is really a good situation,
> in order to solve a problem that is not solved you and I think the other
> developers of firebird introduced the returning of zero.
> Jason, who all us knows well, said I will not fix IBO for a bug in the
> So for someone like me and other people posting on IBO-Listthe
> this is really a mess.
> I have to change the IBO code (not for a general part) but for myself
> in order to use views.
> Also sorry but at least I agree to jason, this is a "bug" introduced in
> latestzero?
> release.
> I have never encountered problems with rows affected before.
> Also why don't you think about Jason proposal to return -1 instead of
> Regards
> Marco
>