Data type "indicator" - What about boolean?

[Fabian Gorsler]

Hi,

a new day, a new question. ;)

First of all: Should the data type "indicator" be interpreted as the
good old diode, glowing up to indicate s.o. s.th. special, or perhaps as
a kind of error level, like the DEFCONs with multiple meanings for each
level?

I for myself interpret it as a glowing diode and I'm wondering about the
SQL-type mapped to indicator: It's CHAR(1), but not BOOLEAN like (some)
databases would understand. Is there any background why CHAR(1) is used?

I know that MySQL didn't/doesn't(?) support BOOLEAN as type (for a long
time), but RDBMS like Postgres or Oracle support it and it's even
documented in the SQL-standard (Postgres docs say this.). Are there
perhaps any OFBiz-internal things which could cause serious problems
when using BOOLEAN?

Additionally I should say I'm developing on a Postgres-DB which will
changed to a Oracle-DB when the software will be productively used.

TIA

Best regards,
     Fabian.

[Andrew Sykes]

Fabian,

"indicator" is used as a boolean, and you are correct, not all DBs
support Boolean, but they all support char, hence the use of the Y/N
format.

- Andrew

On Fri, 2006-07-07 at 10:03 +0200, Fabian Gorsler wrote:

> Hi,
>
> a new day, a new question. ;)
>
> First of all: Should the data type "indicator" be interpreted as the
> good old diode, glowing up to indicate s.o. s.th. special, or perhaps as
> a kind of error level, like the DEFCONs with multiple meanings for each
> level?
>
> I for myself interpret it as a glowing diode and I'm wondering about the
> SQL-type mapped to indicator: It's CHAR(1), but not BOOLEAN like (some)
> databases would understand. Is there any background why CHAR(1) is used?
>
> I know that MySQL didn't/doesn't(?) support BOOLEAN as type (for a long
> time), but RDBMS like Postgres or Oracle support it and it's even
> documented in the SQL-standard (Postgres docs say this.). Are there
> perhaps any OFBiz-internal things which could cause serious problems
> when using BOOLEAN?
>
> Additionally I should say I'm developing on a Postgres-DB which will
> changed to a Oracle-DB when the software will be productively used.
>
> TIA
>
> Best regards,
>      Fabian.

... [show rest of quote]

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Fabian Gorsler]

Oh, excuse me, I've mixed up data types in Oracle. In Oracle the RDBMS
itself has noch BOOLEAN, just PL/SQL supports it.

But anyway: Why is there no explicit data type fo just logical
data with an abstraction to something like "true" and "false"? Perhaps
NUMBER(1) could be used even on different RDBMS which don't support
BOOLEAN.

[Andrew Sykes]

Fabian,

This would mean "parsing" every indicator field.

Not good for performance!

On Fri, 2006-07-07 at 10:38 +0200, Fabian Gorsler wrote:
> Oh, excuse me, I've mixed up data types in Oracle. In Oracle the RDBMS
> itself has noch BOOLEAN, just PL/SQL supports it.
>
> But anyway: Why is there no explicit data type fo just logical
> data with an abstraction to something like "true" and "false"? Perhaps
> NUMBER(1) could be used even on different RDBMS which don't support
> BOOLEAN.
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Fabian Gorsler]

Yes, that's true. The number of operations on those fields would grow on
several layers of OFBiz (At the moment I'm not sure whether I've understood
the complete architecture.). Up to now I've just thought about a strict rule
for storing data with logical values, not about performance.

Thanks for your explanations. :)

Best regards,
     Fabian.