|Subject||Re: [IB-Architect] Trigger Templates|
> Joseph: can you narrow your expectations and proposed solutions to adegree
>that doesn't demand 15 years of future effort?Claudio, Remember... Think OPEN SOURCE. There is no limit to community
effort, and what you can do when you have the whole world... The only upper
limit of Open Source is VISION. That's what I'm trying to say.
My guess is IB Object-Oriented will not be very hard to do. For one thing,
(I think), BLR has the basic capacity to do Object-Oriented "emulation" even
>I have nothing specialand
>against your ideas, but again let's go back to the horse-before-cart level:
>what are your immediate and most tiresome activities that drive you nuts
>that can be addressed maybe in a few months of development?That's precisely this. REPETITIVE CODES, triggers with exactly the same
bodies, requiring only different headers. This is probably because my
object-oriented mindset - due to using UML analysis makes it such that I
begin to notice so many similarites.
Come to think of it... the POSITION feature of the trigger can even be used
in object-oriented techniques later.
> For example, if you do a task from 40 triggers that do the same thing andexactly. Again, the analogy of ROLES. Before, when IB did not have roles, we
>you would be able to write code like this in every trigger:
>execute procedure generic(current_relation, old, new)
were content with having EXECUTE procedures granting privileges to
individual users. But now that IB has roles, would you go back to the same
In my opinion, the implementation of Template Triggers can be similar to
roles. Have a template trigger, and these template triggers can be
referenced by Utilizing tables. (I'm using Utilizing to highlight the fact
that at present, triggers are singularly and statically linked to a table...
which in my opinion will soon get out-moded. Utilizing means, triggers
should have a looser, more dynamic attachment to tables. They should be more
like TOOLS and USED_BY relationship rather than an OWNED_BY relationship
> As Fabricio Araujo wrote in IB-Conversions, MsSql procedures are alreadyBy analogy... COBOL looks beautiful. How would you compare it with C++. Or
>somewhat unreadable. IB procedures have a clean and easy syntax instead.
>They can be learned by newbies in short time. Please, don't destroy their
>beauty with a lot of radical changes in the syntax.
even Delphi? I guess beauty and use is in the eyes of the beholder.
> Each time a product receives a ton of new features in a row, disastercompromised
>happens. Borland had to learn that lesson the hard way when they
>the stability and credibility of Delphi (gained with D3) due to a reallybug
>horrible D4 release. Thanks to that, I lost 2 good client companies; they
>migrated to VB because D4 was virtually unusable when it was released =>
>over bug. We don't need to repeat the story. Being cautious is notREMEMBER... INPRISE WON'T BE WRITING THE NEW IB CODE. WE WILL BE!!! THIS
>necessarily the same than being conservative and obsolete.
> In other post, you wrote:7 is a pretty old number, I agree. Check out 8.0.5 or 8.1.5.
>> Lastly, other database servers are going object-oriented to eliminate the
>> impedance between object-oriented analysis (like UML) and database
>> implementations like IB. (Oracle already has object-oriented features).
> The last time I checked Oracle's OO features (v7.X) they were more
>marketing than reality.
> It seems like you haven't worked with OO databases. In early 1996, IPoint taken. Similar experience... and sacrifice.
>abandoned IB to pursue the mythical aim of developing ....
>code. That language would be Java probably (I would prefer C++, but...)me too... but Java is quite okay. I'm using it now to program handhelds
> Disclaimer: I'm not saying Joseph's ideas are useless or totally out offeatures
>context. But I want to draw a line among features on the engine and
>on external tools.I can only offer Professor Nozaki's 3 points for development.
1. What do we want? -- Look as far as you can/ as high as you can.
2. What do we have? -- What are our resources. Can we do it.
3. What can we do? -- Task list. Day-to-day.
It would be clear from these three points that if you start only at number
two, the community will be doomed to obsolescence in a few years time.
I would certainly want to revive that Gung-ho, non-conformist attitude that
the Young Bad Wolf had that pushed him to go beyond the limits of his day,
and realize that there is a way out of those oppressive locks, so that
readers need not lock out writers.
We have new challenges today. Are we content of looking back at yesterday's
triumphs? Or do we forge ahead?
If we want to forge ahead, I would suggest that we seriously look at the
present (very rapid) advances of ANALYSIS, and think about IB
IMPLEMENTATION. That's how IB could leave the pack behind. (I'm thinking of
developing something like Rational Rose for IB)
It is time to get back that LEGACY of 'NO LOCKS' instead of timidity.