default ij protocol (was Re: [WWD] review suspended)

[Andrew McIntyre <mc...@gmail.com>]

On 2/23/06, Satheesh Bandaram <sa...@sourcery.org> wrote:
> Andrew McIntyre wrote:
> >
> > java -jar lib/derbytools.jar ij
>
> IJ started without using the scripts seems to need a JDBC URL to
> connect. This may not be obvious to everyone and may seem odd to
> non-JDBC/java users. Should IJ (and other tools) be changed to assume
> "jdbc:derby:" protocol by default, if not provided? IJ is Derby's SQL
> processor, so it seems it should be ok to assume derby URL format, if
> none provided?

Moving this over to derby-dev.

This is an excellent question, and one that we need to think about
before we start documenting this.

In the past ij had been a derby-agnostic tool by default, and I think
that we want it to remain so. But, making the default protocol be
jdbc:derby: will definitely make it easier for user's (especially ones
that know nothing about JDBC URLs), so there's definite value there.
Also, specifying a default protocol doesn't preclude you from
connecting to another database (or at least, it shouldn't) - and doing
that would require knowing about classpath and JDBC URLs *anyway* - so
I think maybe this is a non-issue and something we should just do. It
does change default behavior, but not in a way that should have any
impact.

Anyone else have a different opinion?

andrew

Re: default ij protocol (was Re: [WWD] review suspended)

[Andrew McIntyre <mc...@gmail.com>]

On 2/24/06, Satheesh Bandaram <sa...@sourcery.org> wrote:
>
> I thought we have two setup scripts, one for embedded use and another
> for network server/client?

This is true, but if we're not using the scripts to start ij, but
using java -jar, then it would be nice to a) report which mode on
startup, and b) tell the user how to switch. There's already an easy
way to switch: PROTOCOL 'jdbc:derby:net' - although I think we should
again report the mode if that is called (e.g. embedded, client,
non-Derby protocol)

Plus, the duplication of scripts for the tools seems counterintuitive,
and I'd like to avoid it with the new scripts that I'm writing.

> >marsden        Somthing. I don't know what. And a message "Starting ij in
> >embedded mode. To connect to network server ..." or some suc
>
> This sounds good... Though not sure if IJ would know at the startup
> whether embedded or network mode is going to be used. Same IJ can be
> used to connect to both local and remote connections. But if classpath
> doesn't have derby.jar, may be it can assume client/server mode.

derbytools.jar has both derby.jar and derbyclient.jar on its
Class-Path. I think we should default into embedded mode since we
don't know what the user would want, but then when we report the mode
at startup we can also give them the command to switch to the net
client, and it's only one command away and right in front of them. :-)

Add to my wishlist for ij the syntax HELP [COMMAND]. Some of the
commands could use a little more explanation than just what is on the
one help screen we have now.

And isn't LOCALIZEDDISPLAY mode gone? I just noticed its still there
in the help text.

andrew

Re: default ij protocol (was Re: [WWD] review suspended)

[Satheesh Bandaram <sa...@Sourcery.Org>]

Good discussion... Some comments, below..

Andrew McIntyre wrote:

>marsden	We were talking about your ij proposal.
>marsden	Will it confuse network server users who might
>marsden	1) Start network server
>marsden	2) ij> connect 'mydb;create=true';
>marsden	but will actually connect embedded.
>marsden	They won't figure it out until they see a dual boot message
>connecting from another jvm or find their database was created in the
>wrong place
>
>samcintyre	an excellent question. the answer is yes, maybe. definitely
>something to point out in the docs. I think one of Dan's goal for his
>holistic getting started approach was to get people executing SQL as
>quickly as possible. In this case it would mean not even starting
>Network Server.
>  
>
IJ started using framework scripts today have default protocol set. So,
some users might already be familiar with connecting without protocol.

>marsden	ok
>
>samcintyre	I've always thought ij needed a way to default to
>connecting with the net client, but i've not thought it through much.
>samcintyre	perhaps a command line option? ij -client? something seems
>weird about that, but...
>  
>
I thought we have two setup scripts, one for embedded use and another
for network server/client?

>marsden	Somthing. I don't know what. And a message "Starting ij in
>embedded mode. To connect to network server ..." or some suc
>  
>
This sounds good... Though not sure if IJ would know at the startup
whether embedded or network mode is going to be used. Same IJ can be
used to connect to both local and remote connections. But if classpath
doesn't have derby.jar, may be it can assume client/server mode.

>samcintyre	(speaking of which, that's another thing ij needs, is a
>usage message a --help or -? option)
>
>marsden	I don't have any good ideas. I just found the default a little worrisome
>
>jta	--help would be great
>
>marsden	just more great stuff to do....
>
>samcintyre	actually, I think that's a great idea, Kathey. The ij
>embedded vs. ij client distinction has been a problem since network
>server arrived. A message stating which mode you're in, as well as
>instructions on how to switch modes seems to hit the mark.
>
>samcintyre	Yes, we always seem to be very good at coming up with
>things to do. :-)
>
>marsden	I remember when I first started with Cloudscape I had the
>hardest time getting my head around the idea of an embedded database.
>I cannot remember now why, but I know it happens to a lot of new
>users.
>
>marsden	Before you came, Deepa had made mention of DERBY-597 and J2ME.
>Whatever is done in terms of defaults, it would be good to consider
>J2ME and ij.dataSource as well.
>
>samcintyre	ok. haven't looked at 597 in a while. Seems like ij could
>detect a J2ME environment by checking JVMInfo and switch to a
>datasource, regardless of whether ij.protocol was set. That would
>require having a default for ij.datasource as well.
>
>samcintyre	yes, looks like 597 didn't set a default, just switches to
>use the datasource if no protocol is provided in the URL.
>
>Deepa[1]	checking JVMInfo sounds like a good idea. currently ij just
>checks for ij.datasource property and if found uses it to get the
>connection.
>Deepa[1]	connect url should not have the protocol part in it.
>something like ij> connect 'mydb;create=true';
>
>samcintyre	yes. what if ij.protocol is set? I guess we could likewise
>detect a J2ME environment and not set a default protocol in that case.
>
>Deepa[1]	test harness sees if ij.dataSource is set and removes
>ij.database and ij.protocol from the system properties
>Deepa[1]	so we may need to do what you said "detect a J2ME environment
>and not set a default protocol"
>
>samcintyre	right, that would be happening in ij, not in the test harness.
>
>
>
>  
>

Re: default ij protocol (was Re: [WWD] review suspended)

[Andrew McIntyre <mc...@gmail.com>]

And, I just had a chat with Deepa, Kathey, and Jean on IRC that I will
summarize below, where several concerns about how this might affect
the user in a client/server setting were discussed, along with some
good ideas concerning ij, default protocols and the use of DataSources
in J2ME were discussed.

andrew


marsden	Hi andrew. Were your ears ringing?

samcintyre	:-) no, i just decided to show up. got a question for me?

marsden	We were talking about your ij proposal.
marsden	Will it confuse network server users who might
marsden	1) Start network server
marsden	2) ij> connect 'mydb;create=true';
marsden	but will actually connect embedded.
marsden	They won't figure it out until they see a dual boot message
connecting from another jvm or find their database was created in the
wrong place

samcintyre	an excellent question. the answer is yes, maybe. definitely
something to point out in the docs. I think one of Dan's goal for his
holistic getting started approach was to get people executing SQL as
quickly as possible. In this case it would mean not even starting
Network Server.

marsden	ok

samcintyre	I've always thought ij needed a way to default to
connecting with the net client, but i've not thought it through much.
samcintyre	perhaps a command line option? ij -client? something seems
weird about that, but...

marsden	Somthing. I don't know what. And a message "Starting ij in
embedded mode. To connect to network server ..." or some such

samcintyre	(speaking of which, that's another thing ij needs, is a
usage message a --help or -? option)

marsden	I don't have any good ideas. I just found the default a little worrisome

jta	--help would be great

marsden	just more great stuff to do....

samcintyre	actually, I think that's a great idea, Kathey. The ij
embedded vs. ij client distinction has been a problem since network
server arrived. A message stating which mode you're in, as well as
instructions on how to switch modes seems to hit the mark.

samcintyre	Yes, we always seem to be very good at coming up with
things to do. :-)

marsden	I remember when I first started with Cloudscape I had the
hardest time getting my head around the idea of an embedded database.
I cannot remember now why, but I know it happens to a lot of new
users.

marsden	Before you came, Deepa had made mention of DERBY-597 and J2ME.
Whatever is done in terms of defaults, it would be good to consider
J2ME and ij.dataSource as well.

samcintyre	ok. haven't looked at 597 in a while. Seems like ij could
detect a J2ME environment by checking JVMInfo and switch to a
datasource, regardless of whether ij.protocol was set. That would
require having a default for ij.datasource as well.

samcintyre	yes, looks like 597 didn't set a default, just switches to
use the datasource if no protocol is provided in the URL.

Deepa[1]	checking JVMInfo sounds like a good idea. currently ij just
checks for ij.datasource property and if found uses it to get the
connection.
Deepa[1]	connect url should not have the protocol part in it.
something like ij> connect 'mydb;create=true';

samcintyre	yes. what if ij.protocol is set? I guess we could likewise
detect a J2ME environment and not set a default protocol in that case.

Deepa[1]	test harness sees if ij.dataSource is set and removes
ij.database and ij.protocol from the system properties
Deepa[1]	so we may need to do what you said "detect a J2ME environment
and not set a default protocol"

samcintyre	right, that would be happening in ij, not in the test harness.

Re: default ij protocol (was Re: [WWD] review suspended)

[Stanley Bradbury <St...@gmail.com>]

Myrna van Lunteren wrote:

> On 2/24/06, *Andrew McIntyre* <mcintyre.a@gmail.com 
> <ma...@gmail.com>> wrote:
>
>     On 2/23/06, Satheesh Bandaram <satheesh@sourcery.org
>     <ma...@sourcery.org>> wrote:
>     > Andrew McIntyre wrote:
>     > >
>     > > java -jar lib/derbytools.jar ij
>     >
>     > IJ started without using the scripts seems to need a JDBC URL to
>     > connect. This may not be obvious to everyone and may seem odd to
>     > non-JDBC/java users. Should IJ (and other tools) be changed to
>     assume
>     > "jdbc:derby:" protocol by default, if not provided? IJ is
>     Derby's SQL
>     > processor, so it seems it should be ok to assume derby URL
>     format, if
>     > none provided?
>         ======  SNIP  ====
>
>     I think maybe this is a non-issue and something we should just do. It
>     does change default behavior, but not in a way that should have any
>     impact.
>
>     Anyone else have a different opinion?
>
>     andrew
>
>
>  
> I wonder - could we leave ij alone, and in run.java add the check for 
> protocol? That way, we leave all the capabilities of calling ij using 
> the old scripts exactly as is, yet provide the ease of use of running 
> java -jar derbytools.jar ij with a default protocol?
>  
> Myrna

If the change is just to create a default for ij.protocol then this 
should have no impact on existing applications.  I like the idea so

+1

Re: default ij protocol (was Re: [WWD] review suspended)

[Andrew McIntyre <mc...@gmail.com>]

On 2/24/06, Myrna van Lunteren <m....@gmail.com> wrote:
>
> I wonder - could we leave ij alone, and in run.java add the check for
> protocol? That way, we leave all the capabilities of calling ij using the
> old scripts exactly as is, yet provide the ease of use of running java -jar
> derbytools.jar ij with a default protocol?

Yes, we could. Although, it seems to me that the behavior wouldn't be
any different if we just made it the default in ij itself. The old
scripts, for example, would continue to work as-is just as they would
before. And, if you were connecting to a database using a non-Derby
JDBC driver with a fully qualified URL, again no change in current
behavior. And, if the change was in ij, then you get the benefit of
the default protocol if you call the class directly as well.

andrew

Re: default ij protocol (was Re: [WWD] review suspended)

[Myrna van Lunteren <m....@gmail.com>]

On 2/24/06, Andrew McIntyre <mc...@gmail.com> wrote:
>
> On 2/23/06, Satheesh Bandaram <sa...@sourcery.org> wrote:
> > Andrew McIntyre wrote:
> > >
> > > java -jar lib/derbytools.jar ij
> >
> > IJ started without using the scripts seems to need a JDBC URL to
> > connect. This may not be obvious to everyone and may seem odd to
> > non-JDBC/java users. Should IJ (and other tools) be changed to assume
> > "jdbc:derby:" protocol by default, if not provided? IJ is Derby's SQL
> > processor, so it seems it should be ok to assume derby URL format, if
> > none provided?
>
> Moving this over to derby-dev.
>
> This is an excellent question, and one that we need to think about
> before we start documenting this.
>
> In the past ij had been a derby-agnostic tool by default, and I think
> that we want it to remain so. But, making the default protocol be
> jdbc:derby: will definitely make it easier for user's (especially ones
> that know nothing about JDBC URLs), so there's definite value there.
> Also, specifying a default protocol doesn't preclude you from
> connecting to another database (or at least, it shouldn't) - and doing
> that would require knowing about classpath and JDBC URLs *anyway* - so
> I think maybe this is a non-issue and something we should just do. It
> does change default behavior, but not in a way that should have any
> impact.
>
> Anyone else have a different opinion?
>
> andrew
>


I wonder - could we leave ij alone, and in run.java add the check for
protocol? That way, we leave all the capabilities of calling ij using the
old scripts exactly as is, yet provide the ease of use of running java -jar
derbytools.jar ij with a default protocol?

Myrna