Subject | Re: [firebird-support] Domains in SP Parameters. |
---|---|
Author | Jacqui Caren |
Post date | 2004-10-06T14:09:25Z |
xyvy wrote:
My "Things to do" are (not in any order)
* make the perlre's a lot more flexible.
* use perl's $dbh->do() command to create/drop stuff.
* extract any preceding comment and place the contents in
the SP's description field.
I really miss oracle's 'comment on object as ....'
but that is a totally different can or worms :-)
* create a DBM holding a list of things that failed to load
- this will allow runs to remember failures.
- it will also allow a single reload run to
skip multi -reload attempts (due to dependancies)
* it does NOT cover all data types (IIRC)
- 1 *think* "blob sub_type 1" works but this is the
only sub_type currently in use in our schema.
As I said it is very crude and does the bare minimum of what
I require and no more.
If a different 'type' convention is used by Firebird then I
will drop my script and start using the official version - until
then this very "Oraclish" way of typing things suits me fine.
p.s.
Note that I added table.field%type and domain%type on purpose.
In my situation (some) field domains can change without notice
and I use table.field%type. In some generic SP's I use a domain
that I *know* will not change - this works for me - YMMV
Note that I am NOT suggesting that Firebird implement the model I
am using - consider the script as nothing more than a temporary "hack".
> This script is fantastic,IMHO It is "dog poo".
My "Things to do" are (not in any order)
* make the perlre's a lot more flexible.
* use perl's $dbh->do() command to create/drop stuff.
* extract any preceding comment and place the contents in
the SP's description field.
I really miss oracle's 'comment on object as ....'
but that is a totally different can or worms :-)
* create a DBM holding a list of things that failed to load
- this will allow runs to remember failures.
- it will also allow a single reload run to
skip multi -reload attempts (due to dependancies)
* it does NOT cover all data types (IIRC)
- 1 *think* "blob sub_type 1" works but this is the
only sub_type currently in use in our schema.
As I said it is very crude and does the bare minimum of what
I require and no more.
> but should not be better that SPs and TriggersIt would be far better to "do it right" but I could not wait.
> support them?
If a different 'type' convention is used by Firebird then I
will drop my script and start using the official version - until
then this very "Oraclish" way of typing things suits me fine.
p.s.
Note that I added table.field%type and domain%type on purpose.
In my situation (some) field domains can change without notice
and I use table.field%type. In some generic SP's I use a domain
that I *know* will not change - this works for me - YMMV
Note that I am NOT suggesting that Firebird implement the model I
am using - consider the script as nothing more than a temporary "hack".