Hello Jesse,
A couple quick questions involving the install process.
It makes the most sense to me to have the user create the DB2 database and
tablespaces, so that he can decide if he wants system or database managed
tablespaces, etc. Also, if the DB server is on a another machine, it also
makes sense to make the use catalog the remote instance locally. (DB2
cannot do remote connects, you have to install a small DB2 instance on the
local machine, which does nothing but relay data back and fourth between
itself and the server, so it makes all DB2 calls to localhost as far as the
API in concerned)
Does that seem to work with you?
There are just far too many variables in how people like to set up their
databases for me to want to do that part in the Makefile/initdb scripts.
Creating the tables, on the other hand, would be very easy to work once the
empty database is created.
Let me know if this seems to jive with your idea of the userfriendliness of
RT and I’ll start working on getting 1.3 to at least create the table in my
DB server.
Woould it be possible for the initdb.DB2 to check to see if it had already
been set up and if it hadn’t to pick some “sane” defaults as determined by you?
While I’d like to give admins flexibilty, working out of the tarball with a minimum of hassle is an important criterion to consider.
Hello Jesse,
A couple quick questions involving the install process.
It makes the most sense to me to have the user create the DB2 database and
tablespaces, so that he can decide if he wants system or database managed
tablespaces, etc. Also, if the DB server is on a another machine, it also
makes sense to make the use catalog the remote instance locally. (DB2
cannot do remote connects, you have to install a small DB2 instance on the
local machine, which does nothing but relay data back and fourth between
itself and the server, so it makes all DB2 calls to localhost as far as the
API in concerned)
Does that seem to work with you?
There are just far too many variables in how people like to set up their
databases for me to want to do that part in the Makefile/initdb scripts.
Creating the tables, on the other hand, would be very easy to work once the
empty database is created.
Let me know if this seems to jive with your idea of the userfriendliness of
RT and I’ll start working on getting 1.3 to at least create the table in my
DB server.
jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
‘“As the company that brought users the Internet, Netscape is now inviting
the more than 60 million people who have used our client software to
‘tune up’ and upgrade to Netscape Communicator,” said Mike Homer,
senior vice president of marketing at Netscape.’ Sometimes I wonder.
jesse> Woould it be possible for the initdb.DB2 to check to see if it had
jesse> already been set up and if it hadn’t to pick some “sane” defaults as
jesse> determined by you? While I’d like to give admins flexibilty, working
jesse> out of the tarball with a minimum of hassle is an important criterion
jesse> to consider.
Provide the option to allow RT to do the init, yes – but just keep it easily
separable so that people that want to do it themselves don’t have to whack
the setup code. A flag one way or the other would be best, IMO.
jesse> Woould it be possible for the initdb.DB2 to check to see if it had
jesse> already been set up and if it hadn’t to pick some “sane” defaults as
jesse> determined by you? While I’d like to give admins flexibilty, working
jesse> out of the tarball with a minimum of hassle is an important criterion
jesse> to consider.
Provide the option to allow RT to do the init, yes – but just keep it easily
separable so that people that want to do it themselves don’t have to whack
the setup code. A flag one way or the other would be best, IMO.
jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
…realized that the entire structure of the net could be changed to be made
more efficient, elegant, and spontaneously make more money for everyone
involved. It’s a marvelously simple diagram, but this form doesn’t have a way
for me to draw it. It’ll wait. -Adam Hirsch
Agreed, and I don’t think it makes sense to add DB specific options into the
Makefile, which is why I suggested having the initdb.DB2 be an interactive
script. There are a lot of other config options that will need to be pulled
in as well, so it would probably be relativly easy to have the script
provide these options. I don’t want it all in makefile, as that would
needlessly confuse things for, say, the people who were installing RT on
MySQL.
As long as an instance exists, the script could create the DB. I think that
the scipt should create the tables, of course, but creating the tablespaces
and database will most likely be done by the DBA/whoever is installing RT.
Thanks for the suggestions however, I think I know where I need to start
heading with the install portion of it.
The problem with making these scrips interactive is that it breaks a number
of packaging systems. The default behaviour should be non-interactive and
fully functional.
Agreed, and I don’t think it makes sense to add DB specific options into the
Makefile, which is why I suggested having the initdb.DB2 be an interactive
script. There are a lot of other config options that will need to be pulled
in as well, so it would probably be relativly easy to have the script
provide these options. I don’t want it all in makefile, as that would
needlessly confuse things for, say, the people who were installing RT on
MySQL.
That’s a documentation issue that we can easily take care of.
As long as an instance exists, the script could create the DB. I think that
the scipt should create the tables, of course, but creating the tablespaces
and database will most likely be done by the DBA/whoever is installing RT.
Thanks for the suggestions however, I think I know where I need to start
heading with the install portion of it.
jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
…realized that the entire structure of the net could be changed to be made
more efficient, elegant, and spontaneously make more money for everyone
involved. It’s a marvelously simple diagram, but this form doesn’t have a way
for me to draw it. It’ll wait. -Adam Hirsch
Remember this is a generic thing; it also applies to postgresql, etc…
But it’s not true of every database. Will it be true of the majority of
them? If so, I don’t have an objection to having it be a DB_AUTOINIT_TABLES
with a note that it doesn’t apply to mysql.
Remember this is a generic thing; it also applies to postgresql, etc…
jesse> But it’s not true of every database. Will it be true of the majority
jesse> of them? If so, I don’t have an objection to having it be a
jesse> DB_AUTOINIT_TABLES with a note that it doesn’t apply to mysql.
What I meant was that the choices of where the database server is, what the
database name is, whether to create a new database or just create tables,
etc… are choices that some DBA/admins will want to choose themselves.
That’s a valid point. And there can very easily be DB specific sections in
the Makefile as long as they’re well deliniated and people know they they
only apply if $DB_TYPE == x DB package.
That should be workable.
This got changed a little from what I originally meant, however, in that I
really think RT should continue to create all the tables itself. It was the
database that I was a little concerned about, as the larger RDBMS tend to
have a much more complex database creation method.
However, I’ll all in favor of a DB_AUTOINIT_DATABASE flag that doesn’t apply
to MySQL.
-DylanFrom: Jesse [mailto:jesse@fsck.com]
Sent: Thursday, April 13, 2000 11:50 AM
To: jmr@ncct.sps.mot.com
Cc: Dylan Vanderhoof; ‘rt-devel@lists.fsck.com’
Subject: Re: [rt-devel] A couple quick questions
jesse> DB_DB2_AUTOINIT_TABLES = “Yes”
Remember this is a generic thing; it also applies to postgresql, etc…
But it’s not true of every database. Will it be true of the majority of
them? If so, I don’t have an objection to having it be a DB_AUTOINIT_TABLES
with a note that it doesn’t apply to mysql.
Remember this is a generic thing; it also applies to postgresql, etc…
jesse> But it’s not true of every database. Will it be true of the majority
jesse> of them? If so, I don’t have an objection to having it be a
jesse> DB_AUTOINIT_TABLES with a note that it doesn’t apply to mysql.
What I meant was that the choices of where the database server is, what the
database name is, whether to create a new database or just create tables,
etc… are choices that some DBA/admins will want to choose themselves.
Yep. that’s why it should be configurable in the makefile. But, by default,
RT should pick something and just try to make it happen.
jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
…realized that the entire structure of the net could be changed to be made
more efficient, elegant, and spontaneously make more money for everyone
involved. It’s a marvelously simple diagram, but this form doesn’t have a way
for me to draw it. It’ll wait. -Adam Hirsch
