Обсуждение: Using a preprocessor for constants in SQL

Hi all

When defining records with varchar entries (and at some other places)
something like constants would be useful. They could look something like
this:

DEFINE short = 20;
DEFINE long = 2000;

CREATE TABLE example (
short_string varchar (short),
long_string varchar (long),
long_string2 varchar (long)
);
[...]
CREATE TABLE example200 (
short_name varchar (short),
long_name varchar (long)
);

Like this you could easily change values between test setup and final
deployment. Is there anything like this or is there some elegant way to
achieve this? Or do you all use some sort of preprocessors?

Arthur

At 08:30 AM 2/4/05, Arthur van Dorp wrote:
>When defining records with varchar entries (and at some other places)
>something like constants would be useful. They could look something like this:
>
>DEFINE short = 20;
>DEFINE long = 2000;
>
>CREATE TABLE example (
>short_string varchar (short),
>long_string varchar (long),
>long_string2 varchar (long)
>);
>[...]
>CREATE TABLE example200 (
>short_name varchar (short),
>long_name varchar (long)
>);
>
>Like this you could easily change values between test setup and final
>deployment. Is there anything like this or is there some elegant way to
>achieve this? Or do you all use some sort of preprocessors?


If you change the length of fields between testing and production, it would
invalidate your boundary testing!  What if there is a bug in your code that
presents itself when a field is 200 characters, but not when it is 50
characters long?  There is no difference in disk usage with the example you
gave, so I can see no reason to have different lengths for varchar fields
between test and prod environments.

Frank

> If you change the length of fields between testing and production, it
>  would invalidate your boundary testing!  What if there is a bug in
> your code that presents itself when a field is 200 characters, but
> not when it is 50 characters long?  There is no difference in disk
> usage with the example you gave, so I can see no reason to have
> different lengths for varchar fields between test and prod
> environments.

Uh, ok, bad wording. It's more about easily changing the values during
testing so that I can use the refined code to deploy it. So it's about
ease of change during development, not in the production stage.

But it would be useful even for boundary testing. You can have one
central point to define a few constants and wont forget to adjust them
if you one day decide to change your code.

Thanks

Arthur

> Uh, ok, bad wording. It's more about easily changing the values during
> testing so that I can use the refined code to deploy it. So it's about
> ease of change during development, not in the production stage.

I could probably use "CREATE TYPE" to do something like this. But that
wouldn't be very portable.

Arthur

am  04.02.2005, um 15:29:26 +0100 mailte Arthur van Dorp folgendes:
> >Uh, ok, bad wording. It's more about easily changing the values during
> >testing so that I can use the refined code to deploy it. So it's about
> >ease of change during development, not in the production stage.
>
> I could probably use "CREATE TYPE" to do something like this. But that
> wouldn't be very portable.

You can write a little filter-script with perl, awk, sed, ... to do the
task.


Regards, Andreas
--
Andreas Kretschmer    (Kontakt: siehe Header)
Heynitz:  035242/47212,      D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
 ===    Schollglas Unternehmensgruppe    ===

> You can write a little filter-script with perl, awk, sed, ... to do the
> task.

Yes, sure. I just wanted to avoid using yet another tool if there were
some elegant way around it.

Thanks

Arthur