A report on installing chado

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

A report on installing chado

Karl O. Pinc
Hi,

I've gone ahead on my own and installed some chado
modules and not others, not wanting all of the
modules.  Here is a report of the process I used,
the problems I encountered, and the questions that
arose.  My list of problems are, well, my list of
problems and may not be considered problems when
viewed with other eyes.  Never the less, they seem
worth reporting.

Chado installed from my git repo, converted from
svn r25291 2013-09-09 09:17:56 -0400 (Mon, 09 Sep
2013).

I installed chado into it's own schema, "chado",
instead of "public".  I also installed into
"chado_so", "chado_genetic_code", and
"chado_frange" instead of "so", "genetic_code", and
"frange" since we have a number of schemas and I
wish to clearly identify those schemas which belong
to chado.

I might have worked to patch the problems I found
but I have no feeling for the design goals of the
installation process.  I've done certain amount of
patching and pushing branches to github but after a
point I stopped.  (I've previously notified the
list regarding what's on github.  There's nothing
new.)

Please comment if anyone sees that anything I've
done will cause a problem, if there's a better way
to do something, or regards anything else.

------------------------------------------------
Process:

cd chado/
chado-build-schema.pl

And then selecting the following
modules:

contact
cv
genetic
mage
sequence
expression
organisim
general

And then choosing all the sub-choices, excepting
'godb-bridge', 'chaos-bridge'

The resulting "chado-schema.sql" file was then
edited by hand to change all the schema references
from:
   public to chado
and from
   so to chado_so
and from
   genetic_code to chado_genetic_code
and from
   frange to chado_frange

The create schema code was removed for the "so" and
"genetic_code" and "frange" schema and replaced
with the schema names I wished to use.

References to "so.mrna" and
"genetic_code.gencode_codon_aa" were replaced with
"chado_so.mrna" and
"chado_genetic_code.gencode_codon_aa".

The resultant chado_schema.sql was piped to psql
for installation.


This installs the chado db design schema into a db.
The next step in the INSTALL.Chado document is
"insert baseline data".

The load/etc/initialize.sql was edited by hand
to replace instances of the "public" schema with
"chado".  It was then installed with a script like:

(echo 'set search_path=chado, pg_catalog;'
 cat initialize.sql) \
 | psql -U admin targetdb


This completes the "insert baseline data" step.
The target db was then altered to include the new
chado schemas in the default search_path.  The
search path order I'm using is: chado, chado_so,
chado_genetic_code, chado_frange.

I then granted permission to desired pg roles.

The next step was to create a "profile" in
/usr/local/bin/gmod/conf/.

Add a organism with a statement like:

GMOD_ROOT=/usr/local/gmod gmod_add_organism.pl \
                            --common_name baboon \
                            --dbprofile targetdb

Update the chado version number with a statement
like:

GMOD_ROOT=/usr/local/gmod \
  gmod_chado_properties.pl --dbprofile targetdb \
                           --force \
                           --version 1.23

Hack /usr/local/share/perl5/DBIx/DBSchema/DBD/Pg.pm
so that ontologies can be loaded.  (See Problems
below.)

Build.PL does more stuff to load ontologies than I
wanted to try to figure out, and it was not plain
to me from the INSTALL.Chado document how to use
the underlying tools.  Nor was it clear just how
Build.PL determined the parameters to supply to the
underlying tools.  So, I used the chado Makefile to
install the ontologies (supplying the env vars
GMOD_ROOT, CHADO_DB_NAME, CHADO_DB_USERNAME, and
CHADO_DB_HOST).  (The password was, apparently,
supplied via my ~/.pgpass file.) I loaded
ontologies 1,2,3,4.

Restore
/usr/local/share/perl5/DBIx/DBSchema/DBD/Pg.pm.

------------------------------------------------
Problems:

Upon initial make ./tmp seems a strange and not
particularly sysadmin friendly choice for a tmp
dir.

The documentation makes no mention of the "so",
"genetic_code", and "frange" schemas.  (This is at
least partially rectified in my install-hacks git
branch.)

chado-build-schema.pl barely fits on my screen.  I
had to shift the window about in order to be able
to read and press the buttons at the bottom.

It would be nice not to have to muck around with X.
I tried modules/bin/makedep.pl but I wound up with
a much abbreviated version from that generated by
chado-build-schema.pl.  It might be possible to use
makedep.pl, but there seems to be no wiki
documentation on all the little "sub-module" choices
that chado-build-schema.pl presents so there's no
way to tell what arguments to give makedep.pl.  I
didn't find the documentation presented by
chado-build-schema.pl all that helpful, perhaps
because I'm not really familiar with the problem
domain but also because the gui dialog formatting
was lacking and sometimes truncated or otherwise
made reading difficult.  In a few cases I perused
the xml files but was not well rewarded and decided
instead to push forward and install all the
"sub-modules".

Schema names are hardcoded in a number of places.

The chado_schema.sql file deliberately generates
errors (due to deleting tables that do not yet
exist).  These errors drown out any legitimate
errors that may occur during the installation
process.

The chado_schema.sql file is chatty and delivers
lots of notices and sql results that also serve to
drown out any messages that might indicate
problems in the installation.

The chado_schema.sql file deletes tables.  This
seems like a bad idea should the script be
accidentally run in a valuable db.  Better to
unbundle table deletion from table creation.

The chado_schema.sql file should probably be
wrapped in a transaction, as should the other
install processes.

/usr/local/gmod/conf/ is not an FHS (Filesystem
Hierarchy Standard) compliant place to put
configuration files.

The chado version number in svn head seems to be
that of the last release.  Changing it to something
like 1.24dev after, say, the 1.23 release might
make things easier to track when working from head.

/usr/local/share/perl5/DBIx/DBSchema/DBD/Pg.pm,
aka, DBIx::DBSchema::DBD:Pg is, apparently, broken.
The "public" schema is hardcoded.  I kluged this by
temporary changing "public" to "chado" for the
purpose of loading ontologies.  I did not report a
bug since I'm not really sure where the problem
really is.  (This is a little disturbing since if
the problem is in DBIx::DBSchema::DBD:Pg it's been
there since, I think, PG 7.4 which was released in
2003.)

When running "make ontologies" the CHADO_DB_NAME
is, apparently, not respected during tests for
previously loaded ontologies.  The process reported
that the ontologies were already loaded when I'd
previously loaded them into a different db.  (The
error message does not make clear what files
were/need to be touched to resolve the issue.)
Deleting the content of the "./tmp" directory
solved the problem.

------------------------------------------------
Questions:

Why do the "so", "genetic_code" and "frange"
schemas exist?

When adding an organism with /usr/local/gmod
gmod_add_organism.pl what is the expected content
of the comment?

------------------------------------------------
Notes:

The materialized_view table is most likely
obsolete as of Postgres >= 9.3.



Thanks for the help.


Regards,

Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: A report on installing chado

Mara Kim-3
Not sure if this is relevant to the materialized_views table, but the
latest CentOS (the distro used by our compute cluster) packages only
provide PostgreSQL version 8.4.  This will probably be updated once
EL7 arrives, but until then it would be a major hassle to try and use
the updated version.  I will also point out that Debian stable is also
only on version 9.1, so backwards compatibility (if that's really the
issue) would still be desirable in that case.

On Tue, Apr 1, 2014 at 3:04 PM, Karl O. Pinc <[hidden email]> wrote:

> Hi,
>
> I've gone ahead on my own and installed some chado
> modules and not others, not wanting all of the
> modules.  Here is a report of the process I used,
> the problems I encountered, and the questions that
> arose.  My list of problems are, well, my list of
> problems and may not be considered problems when
> viewed with other eyes.  Never the less, they seem
> worth reporting.
>
> Chado installed from my git repo, converted from
> svn r25291 2013-09-09 09:17:56 -0400 (Mon, 09 Sep
> 2013).
>
> I installed chado into it's own schema, "chado",
> instead of "public".  I also installed into
> "chado_so", "chado_genetic_code", and
> "chado_frange" instead of "so", "genetic_code", and
> "frange" since we have a number of schemas and I
> wish to clearly identify those schemas which belong
> to chado.
>
> I might have worked to patch the problems I found
> but I have no feeling for the design goals of the
> installation process.  I've done certain amount of
> patching and pushing branches to github but after a
> point I stopped.  (I've previously notified the
> list regarding what's on github.  There's nothing
> new.)
>
> Please comment if anyone sees that anything I've
> done will cause a problem, if there's a better way
> to do something, or regards anything else.
>
> ------------------------------------------------
> Process:
>
> cd chado/
> chado-build-schema.pl
>
> And then selecting the following
> modules:
>
> contact
> cv
> genetic
> mage
> sequence
> expression
> organisim
> general
>
> And then choosing all the sub-choices, excepting
> 'godb-bridge', 'chaos-bridge'
>
> The resulting "chado-schema.sql" file was then
> edited by hand to change all the schema references
> from:
>    public to chado
> and from
>    so to chado_so
> and from
>    genetic_code to chado_genetic_code
> and from
>    frange to chado_frange
>
> The create schema code was removed for the "so" and
> "genetic_code" and "frange" schema and replaced
> with the schema names I wished to use.
>
> References to "so.mrna" and
> "genetic_code.gencode_codon_aa" were replaced with
> "chado_so.mrna" and
> "chado_genetic_code.gencode_codon_aa".
>
> The resultant chado_schema.sql was piped to psql
> for installation.
>
>
> This installs the chado db design schema into a db.
> The next step in the INSTALL.Chado document is
> "insert baseline data".
>
> The load/etc/initialize.sql was edited by hand
> to replace instances of the "public" schema with
> "chado".  It was then installed with a script like:
>
> (echo 'set search_path=chado, pg_catalog;'
>  cat initialize.sql) \
>  | psql -U admin targetdb
>
>
> This completes the "insert baseline data" step.
> The target db was then altered to include the new
> chado schemas in the default search_path.  The
> search path order I'm using is: chado, chado_so,
> chado_genetic_code, chado_frange.
>
> I then granted permission to desired pg roles.
>
> The next step was to create a "profile" in
> /usr/local/bin/gmod/conf/.
>
> Add a organism with a statement like:
>
> GMOD_ROOT=/usr/local/gmod gmod_add_organism.pl \
>                             --common_name baboon \
>                             --dbprofile targetdb
>
> Update the chado version number with a statement
> like:
>
> GMOD_ROOT=/usr/local/gmod \
>   gmod_chado_properties.pl --dbprofile targetdb \
>                            --force \
>                            --version 1.23
>
> Hack /usr/local/share/perl5/DBIx/DBSchema/DBD/Pg.pm
> so that ontologies can be loaded.  (See Problems
> below.)
>
> Build.PL does more stuff to load ontologies than I
> wanted to try to figure out, and it was not plain
> to me from the INSTALL.Chado document how to use
> the underlying tools.  Nor was it clear just how
> Build.PL determined the parameters to supply to the
> underlying tools.  So, I used the chado Makefile to
> install the ontologies (supplying the env vars
> GMOD_ROOT, CHADO_DB_NAME, CHADO_DB_USERNAME, and
> CHADO_DB_HOST).  (The password was, apparently,
> supplied via my ~/.pgpass file.) I loaded
> ontologies 1,2,3,4.
>
> Restore
> /usr/local/share/perl5/DBIx/DBSchema/DBD/Pg.pm.
>
> ------------------------------------------------
> Problems:
>
> Upon initial make ./tmp seems a strange and not
> particularly sysadmin friendly choice for a tmp
> dir.
>
> The documentation makes no mention of the "so",
> "genetic_code", and "frange" schemas.  (This is at
> least partially rectified in my install-hacks git
> branch.)
>
> chado-build-schema.pl barely fits on my screen.  I
> had to shift the window about in order to be able
> to read and press the buttons at the bottom.
>
> It would be nice not to have to muck around with X.
> I tried modules/bin/makedep.pl but I wound up with
> a much abbreviated version from that generated by
> chado-build-schema.pl.  It might be possible to use
> makedep.pl, but there seems to be no wiki
> documentation on all the little "sub-module" choices
> that chado-build-schema.pl presents so there's no
> way to tell what arguments to give makedep.pl.  I
> didn't find the documentation presented by
> chado-build-schema.pl all that helpful, perhaps
> because I'm not really familiar with the problem
> domain but also because the gui dialog formatting
> was lacking and sometimes truncated or otherwise
> made reading difficult.  In a few cases I perused
> the xml files but was not well rewarded and decided
> instead to push forward and install all the
> "sub-modules".
>
> Schema names are hardcoded in a number of places.
>
> The chado_schema.sql file deliberately generates
> errors (due to deleting tables that do not yet
> exist).  These errors drown out any legitimate
> errors that may occur during the installation
> process.
>
> The chado_schema.sql file is chatty and delivers
> lots of notices and sql results that also serve to
> drown out any messages that might indicate
> problems in the installation.
>
> The chado_schema.sql file deletes tables.  This
> seems like a bad idea should the script be
> accidentally run in a valuable db.  Better to
> unbundle table deletion from table creation.
>
> The chado_schema.sql file should probably be
> wrapped in a transaction, as should the other
> install processes.
>
> /usr/local/gmod/conf/ is not an FHS (Filesystem
> Hierarchy Standard) compliant place to put
> configuration files.
>
> The chado version number in svn head seems to be
> that of the last release.  Changing it to something
> like 1.24dev after, say, the 1.23 release might
> make things easier to track when working from head.
>
> /usr/local/share/perl5/DBIx/DBSchema/DBD/Pg.pm,
> aka, DBIx::DBSchema::DBD:Pg is, apparently, broken.
> The "public" schema is hardcoded.  I kluged this by
> temporary changing "public" to "chado" for the
> purpose of loading ontologies.  I did not report a
> bug since I'm not really sure where the problem
> really is.  (This is a little disturbing since if
> the problem is in DBIx::DBSchema::DBD:Pg it's been
> there since, I think, PG 7.4 which was released in
> 2003.)
>
> When running "make ontologies" the CHADO_DB_NAME
> is, apparently, not respected during tests for
> previously loaded ontologies.  The process reported
> that the ontologies were already loaded when I'd
> previously loaded them into a different db.  (The
> error message does not make clear what files
> were/need to be touched to resolve the issue.)
> Deleting the content of the "./tmp" directory
> solved the problem.
>
> ------------------------------------------------
> Questions:
>
> Why do the "so", "genetic_code" and "frange"
> schemas exist?
>
> When adding an organism with /usr/local/gmod
> gmod_add_organism.pl what is the expected content
> of the comment?
>
> ------------------------------------------------
> Notes:
>
> The materialized_view table is most likely
> obsolete as of Postgres >= 9.3.
>
>
>
> Thanks for the help.
>
>
> Regards,
>
> Karl <[hidden email]>
> Free Software:  "You don't pay back, you pay forward."
>                  -- Robert A. Heinlein
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema



--
Mara Kim

Ph.D. Candidate
Computational Biology
Vanderbilt University
Nashville, TN

------------------------------------------------------------------------------
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: A report on installing chado

Karl O. Pinc
On 04/02/2014 12:17:33 PM, Mara Kim wrote:
> Not sure if this is relevant to the materialized_views table, but the
> latest CentOS (the distro used by our compute cluster) packages only
> provide PostgreSQL version 8.4.  This will probably be updated once
> EL7 arrives, but until then it would be a major hassle to try and use
> the updated version.  I will also point out that Debian stable is
> also
> only on version 9.1, so backwards compatibility (if that's really the
> issue) would still be desirable in that case.

I'm sure you wouldn't want to get rid of materialized_views instantly,
but RH/Centos/SL, Debian, and Ubuntu users, at least, have the option
of getting Postgres supported packages directly from postgresql.org.

There are some points of interest in this regard.

After some discussion on IRC with the Postgres folks I found that
the Postgres project recommends getting PG directly from them
because of how Postgres upgrades are supported.  The PG project
only supports upgrading your db from one PG release to
the next.  A "release" being defined as, say, from PG 8.3 to 8.4,
_not_ from 8.4.1 to 8.4.2 or 8 to 9.

As it happens, since at least PG 7.2, it's been
possible to dump your db (using the _new_ pg_dump) and restore
(using the _new_ pg_restore) onto any newer PG version, but this
is by accident and not guaranteed.

So, if you're running RHEL 4 (or clones) and PG 7.1 (by way of
example, I forget the exact version numbers) and want to upgrade
to RHEL 5 or 6 running something newer (8.4) you're out of
luck as far as getting support from the Postgres project.
You _may_ get some help, but the lifecycle of the RH releases
is such that they run versions of PG that are entirely
out of support.  _And_, according to the PG project,
there's no supported upgrade path other than from one PG
release to the next.

Of course, in my opinion, there's nothing wrong with
relying on your distro for support, including such
things as getting your PG data from one release of
your distro to the next.  But it's worth knowing just
where you sit with that.  (And relying on your distro
for _all_ your software is awesome because the
distro does the system's integration work to make
sure _all_ the software on your system inter-operates.
And having the distro manage security patching, etc.,
etc.  There's even more to be said for having
your IT department administer everything and not
have to think about it at all.  :)

However, PG being a db and db people being very
conservative, I don't find a problem with backward
compatibility between PG releases.  Running newer
versions of PG work with older software.  This
is one of the PG project's design goals.

The Postgres project supplies not only packages,
but also package repositories that integrate with
the distro's package upgrade systems.  This makes
getting your PG packages directly from the PG
project as easy as getting them from your distro.

So, a good case can be made for getting your PG
directly from the PG project.   This is especially
true on Debian based distros using .deb packages because they
include "one-step" automatic migration of your
data from one PG release to the next.  (See the
/usr/share/postgres*/README.Debian file for
instructions.)  It's rather easy to get the
newer goodness of recent PG releases.  (And
get the security updates soonest as well.)

(RH based distro's have always been a bit
more of a bother to upgrade.  I don't know
if there's anything automated available,
I always wind up doing a full dump and restore
to migrate between major PG releases.)

I will often use the "next to newest"
PG version, say 9.2 rather than 9.3,
instead of the latest when
there's important data involved.  Just in
case.  YMMV.

Regards,

Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: A report on installing chado

Siddhartha Basu
In reply to this post by Mara Kim-3
Hi Mara,
FYI,
The latest version of pg for latest centos are available from
the postgresql repository.
http://yum.postgresql.org/
If you are allowed to use outside/unofficial rpm repos, then this might
be a good choice for upgrade using the yum package manager.

Hope this helps,
-siddhartha

On Wed, 02 Apr 2014, Mara Kim wrote:

> Not sure if this is relevant to the materialized_views table, but the
> latest CentOS (the distro used by our compute cluster) packages only
> provide PostgreSQL version 8.4.  This will probably be updated once
> EL7 arrives, but until then it would be a major hassle to try and use
> the updated version.  I will also point out that Debian stable is also
> only on version 9.1, so backwards compatibility (if that's really the
> issue) would still be desirable in that case.
>
> On Tue, Apr 1, 2014 at 3:04 PM, Karl O. Pinc <[hidden email]> wrote:
> > Hi,
> >
> > I've gone ahead on my own and installed some chado
> > modules and not others, not wanting all of the
> > modules.  Here is a report of the process I used,
> > the problems I encountered, and the questions that
> > arose.  My list of problems are, well, my list of
> > problems and may not be considered problems when
> > viewed with other eyes.  Never the less, they seem
> > worth reporting.
> >
> > Chado installed from my git repo, converted from
> > svn r25291 2013-09-09 09:17:56 -0400 (Mon, 09 Sep
> > 2013).
> >
> > I installed chado into it's own schema, "chado",
> > instead of "public".  I also installed into
> > "chado_so", "chado_genetic_code", and
> > "chado_frange" instead of "so", "genetic_code", and
> > "frange" since we have a number of schemas and I
> > wish to clearly identify those schemas which belong
> > to chado.
> >
> > I might have worked to patch the problems I found
> > but I have no feeling for the design goals of the
> > installation process.  I've done certain amount of
> > patching and pushing branches to github but after a
> > point I stopped.  (I've previously notified the
> > list regarding what's on github.  There's nothing
> > new.)
> >
> > Please comment if anyone sees that anything I've
> > done will cause a problem, if there's a better way
> > to do something, or regards anything else.
> >
> > ------------------------------------------------
> > Process:
> >
> > cd chado/
> > chado-build-schema.pl
> >
> > And then selecting the following
> > modules:
> >
> > contact
> > cv
> > genetic
> > mage
> > sequence
> > expression
> > organisim
> > general
> >
> > And then choosing all the sub-choices, excepting
> > 'godb-bridge', 'chaos-bridge'
> >
> > The resulting "chado-schema.sql" file was then
> > edited by hand to change all the schema references
> > from:
> >    public to chado
> > and from
> >    so to chado_so
> > and from
> >    genetic_code to chado_genetic_code
> > and from
> >    frange to chado_frange
> >
> > The create schema code was removed for the "so" and
> > "genetic_code" and "frange" schema and replaced
> > with the schema names I wished to use.
> >
> > References to "so.mrna" and
> > "genetic_code.gencode_codon_aa" were replaced with
> > "chado_so.mrna" and
> > "chado_genetic_code.gencode_codon_aa".
> >
> > The resultant chado_schema.sql was piped to psql
> > for installation.
> >
> >
> > This installs the chado db design schema into a db.
> > The next step in the INSTALL.Chado document is
> > "insert baseline data".
> >
> > The load/etc/initialize.sql was edited by hand
> > to replace instances of the "public" schema with
> > "chado".  It was then installed with a script like:
> >
> > (echo 'set search_path=chado, pg_catalog;'
> >  cat initialize.sql) \
> >  | psql -U admin targetdb
> >
> >
> > This completes the "insert baseline data" step.
> > The target db was then altered to include the new
> > chado schemas in the default search_path.  The
> > search path order I'm using is: chado, chado_so,
> > chado_genetic_code, chado_frange.
> >
> > I then granted permission to desired pg roles.
> >
> > The next step was to create a "profile" in
> > /usr/local/bin/gmod/conf/.
> >
> > Add a organism with a statement like:
> >
> > GMOD_ROOT=/usr/local/gmod gmod_add_organism.pl \
> >                             --common_name baboon \
> >                             --dbprofile targetdb
> >
> > Update the chado version number with a statement
> > like:
> >
> > GMOD_ROOT=/usr/local/gmod \
> >   gmod_chado_properties.pl --dbprofile targetdb \
> >                            --force \
> >                            --version 1.23
> >
> > Hack /usr/local/share/perl5/DBIx/DBSchema/DBD/Pg.pm
> > so that ontologies can be loaded.  (See Problems
> > below.)
> >
> > Build.PL does more stuff to load ontologies than I
> > wanted to try to figure out, and it was not plain
> > to me from the INSTALL.Chado document how to use
> > the underlying tools.  Nor was it clear just how
> > Build.PL determined the parameters to supply to the
> > underlying tools.  So, I used the chado Makefile to
> > install the ontologies (supplying the env vars
> > GMOD_ROOT, CHADO_DB_NAME, CHADO_DB_USERNAME, and
> > CHADO_DB_HOST).  (The password was, apparently,
> > supplied via my ~/.pgpass file.) I loaded
> > ontologies 1,2,3,4.
> >
> > Restore
> > /usr/local/share/perl5/DBIx/DBSchema/DBD/Pg.pm.
> >
> > ------------------------------------------------
> > Problems:
> >
> > Upon initial make ./tmp seems a strange and not
> > particularly sysadmin friendly choice for a tmp
> > dir.
> >
> > The documentation makes no mention of the "so",
> > "genetic_code", and "frange" schemas.  (This is at
> > least partially rectified in my install-hacks git
> > branch.)
> >
> > chado-build-schema.pl barely fits on my screen.  I
> > had to shift the window about in order to be able
> > to read and press the buttons at the bottom.
> >
> > It would be nice not to have to muck around with X.
> > I tried modules/bin/makedep.pl but I wound up with
> > a much abbreviated version from that generated by
> > chado-build-schema.pl.  It might be possible to use
> > makedep.pl, but there seems to be no wiki
> > documentation on all the little "sub-module" choices
> > that chado-build-schema.pl presents so there's no
> > way to tell what arguments to give makedep.pl.  I
> > didn't find the documentation presented by
> > chado-build-schema.pl all that helpful, perhaps
> > because I'm not really familiar with the problem
> > domain but also because the gui dialog formatting
> > was lacking and sometimes truncated or otherwise
> > made reading difficult.  In a few cases I perused
> > the xml files but was not well rewarded and decided
> > instead to push forward and install all the
> > "sub-modules".
> >
> > Schema names are hardcoded in a number of places.
> >
> > The chado_schema.sql file deliberately generates
> > errors (due to deleting tables that do not yet
> > exist).  These errors drown out any legitimate
> > errors that may occur during the installation
> > process.
> >
> > The chado_schema.sql file is chatty and delivers
> > lots of notices and sql results that also serve to
> > drown out any messages that might indicate
> > problems in the installation.
> >
> > The chado_schema.sql file deletes tables.  This
> > seems like a bad idea should the script be
> > accidentally run in a valuable db.  Better to
> > unbundle table deletion from table creation.
> >
> > The chado_schema.sql file should probably be
> > wrapped in a transaction, as should the other
> > install processes.
> >
> > /usr/local/gmod/conf/ is not an FHS (Filesystem
> > Hierarchy Standard) compliant place to put
> > configuration files.
> >
> > The chado version number in svn head seems to be
> > that of the last release.  Changing it to something
> > like 1.24dev after, say, the 1.23 release might
> > make things easier to track when working from head.
> >
> > /usr/local/share/perl5/DBIx/DBSchema/DBD/Pg.pm,
> > aka, DBIx::DBSchema::DBD:Pg is, apparently, broken.
> > The "public" schema is hardcoded.  I kluged this by
> > temporary changing "public" to "chado" for the
> > purpose of loading ontologies.  I did not report a
> > bug since I'm not really sure where the problem
> > really is.  (This is a little disturbing since if
> > the problem is in DBIx::DBSchema::DBD:Pg it's been
> > there since, I think, PG 7.4 which was released in
> > 2003.)
> >
> > When running "make ontologies" the CHADO_DB_NAME
> > is, apparently, not respected during tests for
> > previously loaded ontologies.  The process reported
> > that the ontologies were already loaded when I'd
> > previously loaded them into a different db.  (The
> > error message does not make clear what files
> > were/need to be touched to resolve the issue.)
> > Deleting the content of the "./tmp" directory
> > solved the problem.
> >
> > ------------------------------------------------
> > Questions:
> >
> > Why do the "so", "genetic_code" and "frange"
> > schemas exist?
> >
> > When adding an organism with /usr/local/gmod
> > gmod_add_organism.pl what is the expected content
> > of the comment?
> >
> > ------------------------------------------------
> > Notes:
> >
> > The materialized_view table is most likely
> > obsolete as of Postgres >= 9.3.
> >
> >
> >
> > Thanks for the help.
> >
> >
> > Regards,
> >
> > Karl <[hidden email]>
> > Free Software:  "You don't pay back, you pay forward."
> >                  -- Robert A. Heinlein
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Gmod-schema mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>
>
> --
> Mara Kim
>
> Ph.D. Candidate
> Computational Biology
> Vanderbilt University
> Nashville, TN
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema