Re: Best choice for column's data type to represent boolean data

[Daniel John Debrunner]

Rick Hillegas wrote:

Hi Ian,

Two issues block the introduction of a BOOLEAN datatype:

1) We need DRDA support in order to transport this type across our 
network layer. I am cautiously optimistic that we will see this type 
appear in the DRDA spec early in 2007. So, soon, this issue will not 
block us.


I don't see this as blocking adding BOOLEAN into the SQL language, we 
have the XML type which is supported in SQL but not JDBC. Incremental 
development is good.


2) DERBY-887, as you note, also blocks us. The behavior of certain casts 
would have to change and that, we believe, would significantly impact 
existing applications. Our rules about backwards compatibility suggest 
that this kind of change can only occur in a major release. That, as you 
note, would be Derby 11.0.


I don't believe enough analysis of this cast issues has happened to 
decide if adding BOOLEAN would require 11.0 or not. I still really can't 
figure out from all the comments in DERBY-887 what people expected to 
happen with the strange queries like id = (0<3) and what does happen. 
And were those DERBY-887 tests run before the BOOLEAN patch was 
committed or after?


I would encourage those that want BOOLEAN and are willing to work on it 
to come to the derby developer list and kick off the discussion there.


Dan.

Re: calling a function over odbc fails

[Marco Schilling]

Knut Anders Hatlen <[EMAIL PROTECTED]> writes:

> 
> Marco Schilling <[EMAIL PROTECTED]> writes:
> 
> > Hello everyone,
> >
> > I wrote a function called CHKANI(ani varchar(50)) and it works
> > pretty fine in ij. Now I try to use it with the DB2 ODBC-Driver and
> > it fails with "... is not recognized as a function or
> > procedure". The statement looks like this: SELECT CHKANI('0123456')
> > AS "ANI", "PHONE" from "APP"."SAMPLE";
> 
> Does CHKANI live in the current schema? Perhaps APP.CHKANI would work?
> 

Hello everyone,

CHKANI was not available in the namespace. I´ve changed the user and now
everything works fine.

Thank you for helping.

Marco

Re: Best choice for column's data type to represent boolean data

[Rick Hillegas]

Hi Ian,

Two issues block the introduction of a BOOLEAN datatype:

1) We need DRDA support in order to transport this type across our 
network layer. I am cautiously optimistic that we will see this type 
appear in the DRDA spec early in 2007. So, soon, this issue will not 
block us.


2) DERBY-887, as you note, also blocks us. The behavior of certain casts 
would have to change and that, we believe, would significantly impact 
existing applications. Our rules about backwards compatibility suggest 
that this kind of change can only occur in a major release. That, as you 
note, would be Derby 11.0.


A lot of people have requested a BOOLEAN datatype. At the same time, 
other people are concerned about backward compatibility. This topic 
unfortunately pits two groups of users against each other.


Regards,
-Rick

Ian Leslie wrote:

Actually I was just opening wishing but I checked the bug database and
found issue 499 https://issues.apache.org/jira/browse/DERBY-499.  Looks
like a lot of work was done and it was almost in but had to backed out
 because of a blocking
issue .  Issue 499 is
tagged as to be fixed in 11.0 but the blocking issue is not committed to
11.0.  Go vote if you want this.

Ian


-Original Message-
From: Bayless Kirtley [mailto:[EMAIL PROTECTED] 


Is there reason to think the next version may support Boolean data type?

  

RE: Best choice for column's data type to represent boolean data

[Ian Leslie]

Actually I was just opening wishing but I checked the bug database and
found issue 499 https://issues.apache.org/jira/browse/DERBY-499.  Looks
like a lot of work was done and it was almost in but had to backed out
 because of a blocking
issue .  Issue 499 is
tagged as to be fixed in 11.0 but the blocking issue is not committed to
11.0.  Go vote if you want this.

Ian


-Original Message-
From: Bayless Kirtley [mailto:[EMAIL PROTECTED] 

Is there reason to think the next version may support Boolean data type?

Re: Best choice for column's data type to represent boolean data

[Michael Segel]

I'm not sure where that came from, however I'm sure its somewhere on the wish 
list. 
Since the boolean type has been around for a while,  and its implemented in 
other databases, its not out of the realm of being added.

With respect to java objects, what are they?

Note: that was a rhetorical question.
The point being is that one can define a boolean data type in terms of how to 
store it within a database. 

POJOs are a different story. 

Before you think about java objects, you're going to want to redesign derby 
itself . 

But that's a different issue.

Sent via BlackBerry.

-Mike Segel
Principal
MSCC
312 952 8175


-Original Message-
From: "Bayless Kirtley" <[EMAIL PROTECTED]>
Date: Thu, 7 Dec 2006 09:20:07 
To:"Derby Discussion" 
Subject: Re: Best choice for column's data type to represent boolean data

Is there reason to think the next version may support Boolean data type?
If so then what about Java Objects?

Bayless


- Original Message - 
From: "Leslie Software" <[EMAIL PROTECTED]>
To: "Derby Discussion" 
Sent: Thursday, December 07, 2006 8:07 AM
Subject: Re: Best choice for column's data type to represent boolean data


Thanks for the advice I was leaning towards the numeric solution but using 
'T' / 'F' as a visual clue makes a lot of sense.  After all until we do have 
a new boolean data type that visual clue is all we have.  I am already 
looking forward to the next version:-)

Ian

- Original Message 
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>

Well the best practice would be to extend the known data types to include a
Boolean. ;-)

There are two options.
You can create a CHAR(1) column, or if the database you could do a
byte/short column as well.

If you use a CHAR(1) you could represent the Boolean as either ('T' or 'F')
or ('Y','N'). You would also want to put a check constraint on the column
only allowing a true and a false value.

You could also use a 1 or a 0 in the column as well and provide the same
check constraint, however using a T/F or Y/N provides a visual cue that
would be missing from a numeric solution.

HTH

-G







__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

Re: Best choice for column's data type to represent boolean data

[Bayless Kirtley]

Is there reason to think the next version may support Boolean data type?
If so then what about Java Objects?

Bayless


- Original Message - 
From: "Leslie Software" <[EMAIL PROTECTED]>

To: "Derby Discussion" 
Sent: Thursday, December 07, 2006 8:07 AM
Subject: Re: Best choice for column's data type to represent boolean data


Thanks for the advice I was leaning towards the numeric solution but using 
'T' / 'F' as a visual clue makes a lot of sense.  After all until we do have 
a new boolean data type that visual clue is all we have.  I am already 
looking forward to the next version:-)


Ian

- Original Message 
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>

Well the best practice would be to extend the known data types to include a
Boolean. ;-)

There are two options.
You can create a CHAR(1) column, or if the database you could do a
byte/short column as well.

If you use a CHAR(1) you could represent the Boolean as either ('T' or 'F')
or ('Y','N'). You would also want to put a check constraint on the column
only allowing a true and a false value.

You could also use a 1 or a 0 in the column as well and provide the same
check constraint, however using a T/F or Y/N provides a visual cue that
would be missing from a numeric solution.

HTH

-G







__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

Re: Best choice for column's data type to represent boolean data

[Leslie Software]

Thanks for the advice I was leaning towards the numeric solution but using 'T' 
/ 'F' as a visual clue makes a lot of sense.  After all until we do have a new 
boolean data type that visual clue is all we have.  I am already looking 
forward to the next version:-)

Ian

- Original Message 
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>

Well the best practice would be to extend the known data types to include a
Boolean. ;-)

There are two options.
You can create a CHAR(1) column, or if the database you could do a
byte/short column as well. 

If you use a CHAR(1) you could represent the Boolean as either ('T' or 'F')
or ('Y','N'). You would also want to put a check constraint on the column
only allowing a true and a false value.

You could also use a 1 or a 0 in the column as well and provide the same
check constraint, however using a T/F or Y/N provides a visual cue that
would be missing from a numeric solution.

HTH

-G







__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

RE: Best choice for column's data type to represent boolean data

[derby]

> 
> I have a need for columns of boolean data to indicate if items in my
> database have (or do not have) certain attributes.  These are all truly
> yes/no values.  For Derby what is the best approach for me to take (I have
> next to zero database experience so I am not aware of any best practices)?
> In my case if I had t pick performance over storage space in this
> application I would choose performance.  I plan to query using these
> values (along with others); for example select all items that have
> attribute A but not attribute B.
> 
> Currently my application is using 10.1.3.1 but before my next release I
> will be upgrading to 10.2.1.6.
> 
> Thanks,
> 
> Ian
> 
Well the best practice would be to extend the known data types to include a
Boolean. ;-)

There are two options.
You can create a CHAR(1) column, or if the database you could do a
byte/short column as well. 

If you use a CHAR(1) you could represent the Boolean as either ('T' or 'F')
or ('Y','N'). You would also want to put a check constraint on the column
only allowing a true and a false value.

You could also use a 1 or a 0 in the column as well and provide the same
check constraint, however using a T/F or Y/N provides a visual cue that
would be missing from a numeric solution.

HTH

-G

Re: java method called from a JSP cannot load ClientDriver

[Sisilla]

Thank you, Knut, for your reply and your efforts to help me. It turns out
that the fields I thought contained null values actually contained empty
strings, so the NOT NULL constraints are working fine. ~Sisilla


Knut Anders Hatlen wrote:
> 
> Sisilla <[EMAIL PROTECTED]> writes:
> 
>> Hello Again,
>>
>> It seems that my java program ignores the NOT NULL column constraints
>> that I
>> have declared on my derby database table. What am I missing here? I
>> appreciate any help.
> 
> Hi Sisilla,
> 
> It would be easier to help if you could post the statements you used
> for creating the table and the constraints, as well as an example of a
> statement that violates the constraints.
> 
> -- 
> Knut Anders
> 
> 

-- 
View this message in context: 
http://www.nabble.com/java-method-called-from-a-JSP-cannot-load-ClientDriver-tf2768547.html#a7737325
Sent from the Apache Derby Users mailing list archive at Nabble.com.

Re: calling a function over odbc fails

[Knut Anders Hatlen]

Marco Schilling <[EMAIL PROTECTED]> writes:

> Hello everyone,
>
> I wrote a function called CHKANI(ani varchar(50)) and it works
> pretty fine in ij. Now I try to use it with the DB2 ODBC-Driver and
> it fails with "... is not recognized as a function or
> procedure". The statement looks like this: SELECT CHKANI('0123456')
> AS "ANI", "PHONE" from "APP"."SAMPLE";

Does CHKANI live in the current schema? Perhaps APP.CHKANI would work?

-- 
Knut Anders

calling a function over odbc fails

[Marco Schilling]

Hello everyone,

I wrote a function called CHKANI(ani varchar(50)) and it works pretty fine in 
ij. Now I try to use it with the DB2 ODBC-Driver and it fails with "... is not 
recognized as a function or procedure". The statement looks like this: SELECT 
CHKANI('0123456') AS "ANI", "PHONE" from "APP"."SAMPLE";

Any help is appreciated,
thank you very much,

Marco
-- 
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!