Re: Does derby have an embedded Mode like Derby ?

paul_t100@fastmail.fm (Paul Taylor) writes:
> If instead you have to run a database standalone, then you do hit
> configurations problems, not only platform specific issues but also
> people bloody mindness about creating databases with different names
> and database users : whatever the documentation says which has to be
> accounted for in tests. To pretend there are no issues with setting up
> a database is unrealistic.

Actually, it seems to me that these issues are there, regardless.

I have been setting up regression tests lately :-), and what I've had
to do is to set up scripts to manage setting up databases.

I haven't gone so far as demanding to start out with "initdb"; I
assume the presence of a functioning cluster.  Even with that, since
there are ~4 databases to set up, I've got scripts filled with stuff
like:

(Not literally excerpted; this is an excerpt from...
http://main.slony.info/viewcvs/viewvc.cgi/slony1-engine/tests/settings.ik?view=log)

DB1=${DB1:-"slonyregress1"}
HOST1=${HOST1:-"localhost"}
USER1=${USER1:-${PGUSER:-"postgres"}}
WEAKUSER1=${WEAKUSER1:-${WEAKUSER:-${PGUSER:-"weakuser"}}}
PORT1=${PORT1:-${PGPORT:-"5432"}}
PGBINDIR1=${PGBINDIR1:-${PGBINDIR:-"/usr/local/pgsql/bin"}}

DB2=${DB2:-"slonyregress2"}
HOST2=${HOST2:-"localhost"}
USER2=${USER2:-${PGUSER:-"postgres"}}
WEAKUSER2=${WEAKUSER2:-${WEAKUSER:-${PGUSER:-"weakuser"}}}
PORT2=${PORT2:-${PGPORT:-"5432"}}
PGBINDIR2=${PGBINDIR2:-${PGBINDIR:-"/usr/local/pgsql/bin"}}

DB3=${DB3:-"slonyregress3"}
HOST3=${HOST3:-"localhost"}
USER3=${USER3:-${PGUSER:-"postgres"}}
WEAKUSER3=${WEAKUSER3:-${WEAKUSER:-${PGUSER:-"weakuser"}}}
PORT3=${PORT3:-${PGPORT:-"5432"}}
PGBINDIR3=${PGBINDIR3:-${PGBINDIR:-"/usr/local/pgsql/bin"}}

DB4=${DB4:-"slonyregress4"}
HOST4=${HOST4:-"localhost"}
USER4=${USER4:-${PGUSER:-"postgres"}}
WEAKUSER4=${WEAKUSER4:-${WEAKUSER:-${PGUSER:-"weakuser"}}}
PORT4=${PORT4:-${PGPORT:-"5432"}}
PGBINDIR4=${PGBINDIR4:-${PGBINDIR:-"/usr/local/pgsql/bin"}}

I don't think things would be made notably worse if I included
"initdb" in my process.  That would add a few extra steps, and the
mandate that I set up some configuration for:
  a) pg_hba.conf
  b) postgresql.conf
  c) where to find initdb

This would all be somewhat simpler if I were using (say) SQLite.  But
the burdens aren't spectacularly heavy.

And if you choose to run the database in an "embedded-ish" fashion,
then you get to be somewhat "bloodyminded" about how your cluster gets
set up.

I've had the scenario where I had to tell QA (with somewhat more
diplomacy than this ;-)):

  "If you're going to set up databases on the same backend, you can't
  use the same users I have coded with.  If you *DO* get bloody-minded
  about it, and this causes some inconvenience, then it's right well
  YOUR problem that you're not following the stipulations documented
  for the system."

I'm not going to try to force *stupid* constraints on people, but it
doesn't seem to be "out there" to have some details stipulated.

I'll note that in my favorite "common-preferences.sh" file, while
practically everything can be configured, if one were so dumb as to
ask to do so, enough defaults get inherited (via the shell :-
construct) that *USUALLY*, the only values that people need to
configure are:

  a) PGBINDIR, the directory where your favorite PostgreSQL psql
     client lives, and
  b) PGPORT, the port where your favorite cluster answers

I'm pretty happy with this; *EVERYTHING* may be overridden, if need
be, but it is typically sufficient to set those two environment
variables and have things "just work."
--
output = reverse("ofni.sesabatadxunil" "@" "enworbbc")
http://linuxdatabases.info/info/rdbms.html
str->str_pok |= SP_FBM;                     /* deep magic */
s = (unsigned char*)(str->str_ptr);         /* deeper magic */
-- Larry Wall in util.c from the perl source code