| Subject | Re: [IBO]Major problem for me with V4.7.16 |
|---|---|
| Author | Helen Borrie |
| Post date | 2007-02-16T13:40:26Z |
At 11:41 PM 16/02/2007, George wrote:
restrictions imposed by new versions of the database engine. "Dirty"
syntax that people have inadvisedly used in the past will be a
chicken looking for a place to roost.
The tightened join syntax has been presaged for a long time. It
first showed its face during the v.1.5 beta cycle (which was nearly 2
years long), when bad old habits became subject to warnings. Now, at
2.0, they throw frank exceptions. That's one example; there are others.
On the Firebird side, these decisions were not arbitrary. Some
important things remained non-implemented from the InterBase days and
some scary distribution bugs existed for joined sets. People were
warned then to fix up their client code or be prepared for some bad
times with v.2.0.
Fb 2.0 brought along a lot of new challenges for IBO, such things as
derived tables, EXECUTE BLOCK and returning relation aliases in the
statement parameter block. All these things needed supporting,
requiring a lot of changes in the underlying code in the IBO
statement objects that parse the SQL.
So, we've been chewing hard tack for a while, while Jason and Ramil
have been getting it right.
So - the cost for developers of legacy apps *and* of components and
older drivers, who have been less careful than they might have been
about not depending on the "tricks" one can do to exploit a faulty
language implementation, is that The Day of Judgement Has Come.
trivial exercise. For the application developer, it requires fully
researching the changes on the database side and recognising what
work might have to be done in the app code to make it work
properly. For the component developer, it's doubly tricky,
especially so when one has had a suite that was extremely stable with
the older (and still active) v.1.5.
engine is not "routine maintenance". You shouldn't be deploying a
major new version of the database engine without thoroughly testing
its impact on your legacy app code and doing what it takes to make it
work correctly.
yourself time to do the redevelopment necessary.
yourself by always aiming to "code complete". Bending SQL to save a
bit of typing is OK only as long as you can get away with it: it's
going to bite you eventually. If you want to stick with the tricks
then don't upgrade to a version that no longer tolerates them.
You'll never get away with treating a major db engine upgrade as
"routine maintenance". A new release is always going to change
things. The way the db engine market is now, a new release that
doesn't do something radical isn't considered remarkable at all.
Helen
>I am concerned about the wider implications - regardless ofA major new release like v.4.7 is responding to new syntax or new
>the 'correctness' of syntax used in earlier versions.
>
>It seems each new release, instead of building on previous ones,
>creates new problems in existing, tested and released code.
restrictions imposed by new versions of the database engine. "Dirty"
syntax that people have inadvisedly used in the past will be a
chicken looking for a place to roost.
The tightened join syntax has been presaged for a long time. It
first showed its face during the v.1.5 beta cycle (which was nearly 2
years long), when bad old habits became subject to warnings. Now, at
2.0, they throw frank exceptions. That's one example; there are others.
On the Firebird side, these decisions were not arbitrary. Some
important things remained non-implemented from the InterBase days and
some scary distribution bugs existed for joined sets. People were
warned then to fix up their client code or be prepared for some bad
times with v.2.0.
Fb 2.0 brought along a lot of new challenges for IBO, such things as
derived tables, EXECUTE BLOCK and returning relation aliases in the
statement parameter block. All these things needed supporting,
requiring a lot of changes in the underlying code in the IBO
statement objects that parse the SQL.
So, we've been chewing hard tack for a while, while Jason and Ramil
have been getting it right.
So - the cost for developers of legacy apps *and* of components and
older drivers, who have been less careful than they might have been
about not depending on the "tricks" one can do to exploit a faulty
language implementation, is that The Day of Judgement Has Come.
>We have evaluated IBObjects and are seriously consideringMigration is always a risky business and should never be considered a
>incorporating it into our products but we are very concerned about
>configuration control and backward compatibility. From messages in
>this forum, upgrading seems a somewhat risky business, especially if
>considering migrating to Firebird 2.0 from 1.5.
trivial exercise. For the application developer, it requires fully
researching the changes on the database side and recognising what
work might have to be done in the app code to make it work
properly. For the component developer, it's doubly tricky,
especially so when one has had a suite that was extremely stable with
the older (and still active) v.1.5.
>Clients / Users know nothing of IBObjects, (nor should they). AllAnd so it should. Upgrading to a totally new version of the database
>they will see is an application that used to work that now has
>problems after a routine maintenance upgrade. This will reflect badly
>on us.
engine is not "routine maintenance". You shouldn't be deploying a
major new version of the database engine without thoroughly testing
its impact on your legacy app code and doing what it takes to make it
work correctly.
>The only way to avoid these client problems will be to revisitThen don't upgrade to 2.0. Stick with 1.5 and IBO 4.6Aa and give
>all old test scripts from scratch, adding to the admin overhead and
>associated costs. There is also no telling what impact there may be
>on user support documentation.
yourself time to do the redevelopment necessary.
>It is a problem for us and we will monitor the situation beforeI don't think there are any assurances other than those you can give
>making a final decision.
>
>I would welcome any comments or assurances in this area.
yourself by always aiming to "code complete". Bending SQL to save a
bit of typing is OK only as long as you can get away with it: it's
going to bite you eventually. If you want to stick with the tricks
then don't upgrade to a version that no longer tolerates them.
You'll never get away with treating a major db engine upgrade as
"routine maintenance". A new release is always going to change
things. The way the db engine market is now, a new release that
doesn't do something radical isn't considered remarkable at all.
Helen