Re: [Gmod-schema] Re: xml question

[Pinglei Z. <zh...@mo...>]

 
 
 
>> 
>> > Now to address you questions (mostly with more question): first, are you
>> > using the current XML-XORT (ie, the separate repository, not the one
>> > under the schema repository)? Next, when you installed gmod, did you set
>> > up the environment variables as suggested in the INSTALL doc?  If so,
>> > you should get a prompt to use Bio::GMOD::Config when you run XORT's
>> > Makefile.PL.  Answering yes to that should make the XORT installer use
>> > complete.sql which was installed when you installed gmod (it probably
>> > went in /usr/local/gmod/src/modules).  Finally note that I just fixed a
>> > bug in the XORT installer, so if you are using an anonymous checkout, it
>> > may take a day or so for you to get the bug fix (I can send you the
>> > fixed file separately if you want).
>> 
>> I have to admit I'm still a bit confused by the installation process -
>> perhaps XORT should have it's own INSTALL document?
>
>Whoops! Yes, there should be one.  Anyone want to write it?

there is one XML-XORT/README, and another one in more details XML-XORT/doc/readme_xort, is this not enough for INSTALL ? I do 
miss some test files for make test.


>>  Maybe my confusion
>> comes from the fact that I'm currently looking at just XORT & Chado and
>> not trying to install GMOD as a whole. Is this not to be recommended?
>
>Right; so if you start with installing gmod/chado from it's Makefile.PL,
>one of the things that gets installed is Bio::GMOD::Config, which reads
>configuration information from files in /usr/local/gmod/conf.  The XORT
>Makefile.PL checks for the existence of that module and prompts the user
>to use that information.
>> 
>> Is there any reason not to cvs rm the deprecated schema/XMLTools/XORT/
>> directory, since that is now superseded by gmod/XML-XORT?
>
>No, I was reluctant to do it because I didn't want to be responsible for
>losing the history of the files.  If Pinglei doesn't mind, I can ask the
>SF admins to remove that directory.
>> 
>> Note that the xort test suite seems to fail at the moment, due to the
>> absence of a XML::XORT module
>
>Right again; nobody has taken the time to write tests.
>> 
>> Scott - is there any plan to switch to using the SQL::T templates for
>> generating the xort conf files? On the one hand, the existing
>> xort_ddl_properties_creator.pl is a little hacky and is perhaps not robust
>> to changes in the style of DDL. On the other hand, this script seems happy
>> with things like function definitions in the complete.sql file (which I
>> believe SQL::T will barf at). Furthermore, I'm a little worried by the
>> 'CPAN bloat' in SQL::T - it used to be a fairly lightweight module, but
>> the list of dependencies seems to have grown rather a lot. I was
>> previously enthusiastic about a switch to using SQL::T but I'm not so sure
>> now.
>
>I sympathize with your concerns about CPAN bloat.  Bundle::GMOD has
>quite a few modules in it.  My philosophy lately has been, if it
>installs fine with the cpan shell, who cares how many modules there are?

Not really, I am working the doc "using chado to store annotation genome" for CPIB, pretend to be biologist and should be able 
to set up the system with limited knowledge. It turn out to be VERY annoying, seems need endless more modues in order to 
install one  modules. FYI, I am testing it on window with cygwin. core perl come with cygwin have very basical modules. It 
need lots of additional ones for bioperl, XORT, not mention whole GMOD package.  



>That said, SQL::T is currently an optional module for gmod; users only
>need it if they want to modify the schema.  If they don't modify the
>schema, the installer uses default files that are created when I create
>a distribution (well, anytime the schema tables get changed really).  I
>wouldn't mind seeing pregenerated files for XORT living in the chado cvs
>that get used as the default files, while if the user changes the
>schema, they have to let XORT regenerate the files.
>
>As for migrating to SQL::T for XORT, it doesn't matter much to me.  I
>wrote a proof of concept template for generating ddl_properties using
>SQL::T last fall, but it didn't quite work.  I'm sure if we wanted to go
>down that path we could fix it.  The question I have is this: how
>fragile is xort_ddl_properties_creator.pl?  Should we invest the time
>migrating now to save headaches later?

No objection from me to replace xort_ddl_properties_creator.pl if have better way. Actually xort_ddl_properties_creator.pl 
work fine if all create table statements following the same style(e.g how to specify foreign keys). I have to admit only test 
on postgres ddl, not other DBMS ddl.  

>> I think you and Pinglei have done an excellent job documenting all this
>> code & making it easy to use. I think the XORT stuff is 95% there.
>
>Thanks.
>> 
>> I have one request as far as XORT is concerned. Would it not be possible
>> to allow runtime config rather than install-time config. All this setting
>> of chado variables at Makefile.PL stage doesn't seem quite right. I'm not
>> sure why things have to be set in Constants.pm.
>
>I am inclined to agree, but I don't have the time at the moment to make
>the changes.
>> 
>> Surely it would be fairly easy to make Constants.pm lookup a config file
>> at runtime? This could be a standard ini file like this:
>> 
>> [database]
>> name=chado
>> conf_dir=~/chado/conf
>> dbport=5432
>> 
>> [database]
>> name=test_chado
>> conf_dir=~/test_chado/conf
>> 
>> or some xml equivalent?


It is totally doable. 


pinglei