xmlpipedb-developer Mailing List for XMLPipeDB

Worked on the code during the past few days and have committed some changes
tonight.
Also successfully exported without error.
UniProtDatabaseProfile.java
 - clean up of some comments and old code
 - cleaned up logging code for getSystemTableManager()
 - Worked on getRelationshipTableManager()
 - [Uniprot - X conditional]
 - rewrote SQL programmatically
 - used looping to create correct setStrings
 - added logging to surface details
 - -[X - X conditional]
 - rewrite of programmatic SQL is in progress (created stringbuilder
 etc. in preparation)
 - added logging
 - -[Species - X or X - Species]
 - added minimal logging to be expanded upon
DatabaseProfile.java
 - cleaned up comments
 - reviewed getRelationsTableManager() and added some logging to it
ExportToGenMAPP.java
 - cleaned up code and comments for readability
Appreciate any feedback as usual =D
Richard
On Mon, Sep 19, 2011 at 6:22 PM, John David N. Dionisio <do...@lm...>wrote:
> Very cool; looks like we can move on now. Dr. Dahlquist and I suspect that
> the relationship tables may not actually be as hard as they seem; just a
> matter of tweaking the initial queries (which you're more comfortable doing
> now!) so that they return the corresponding records for all of the requested
> species. Onward we go :)
>
> John David N. Dionisio, PhD
> Associate Professor, Computer Science
> Associate Director, University Honors Program
> Loyola Marymount University
>
>
>
> On Sep 19, 2011, at 11:09 AM, Kam Dahlquist wrote:
>
> > Hi,
> >
> > LMU can accept 20 MB attachments now; I don't know how big your file is
> zipped, but that's an option. You could also use LionShare.
> >
> > Glad to see success!
> >
> > Kam
> >
> > At 06:05 PM 9/18/2011, you wrote:
> >> Tried to post my latest gdb export to the biodb wiki but receiving log
> in error (per separate email)
> >>
> >> But, I wanted to let you know I verified that each improper system table
> does in fact contain the id and species name (samples of each):
> >>
> >>
> >> Pfam
> >> ID Species Date
> >> PF02866 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> PF07050 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> PF03479 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> PF02317 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> PF03279 |Pseudomonas aeruginosa| 9/14/2011
> >> PF09922 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> PF04205 |Pseudomonas aeruginosa| 9/14/2011
> >> PF03379 |Pseudomonas aeruginosa| 9/14/2011
> >> PF05389 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >>
> >>
> >> RefSeq
> >> ID Species Date
> >> YP_039973 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> YP_040411 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> YP_039521 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> NP_253798 |Pseudomonas aeruginosa| 9/14/2011
> >> NP_254101 |Pseudomonas aeruginosa| 9/14/2011
> >> NP_248930 |Pseudomonas aeruginosa| 9/14/2011
> >> NP_251503 |Pseudomonas aeruginosa| 9/14/2011
> >> NP_249960 |Pseudomonas aeruginosa| 9/14/2011
> >> NP_253220 |Pseudomonas aeruginosa| 9/14/2011
> >> YP_040877 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> NP_253802 |Pseudomonas aeruginosa| 9/14/2011
> >>
> >>
> >> GeneId
> >> ID Species Date
> >> 879140 |Pseudomonas aeruginosa| 9/14/2011
> >> 2859243 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> 879337 |Pseudomonas aeruginosa| 9/14/2011
> >> 2860668 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> 881899 |Pseudomonas aeruginosa| 9/14/2011
> >> 882312 |Pseudomonas aeruginosa| 9/14/2011
> >> 2860009 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> 881520 |Pseudomonas aeruginosa| 9/14/2011
> >> 2861152 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> 881596 |Pseudomonas aeruginosa| 9/14/2011
> >>
> >>
> >> InterPro
> >> ID Species Date
> >> IPR022522 |Pseudomonas aeruginosa| 9/14/2011
> >> IPR003538 |Pseudomonas aeruginosa| 9/14/2011
> >> IPR016379 |Pseudomonas aeruginosa| 9/14/2011
> >> IPR016920 |Pseudomonas aeruginosa| 9/14/2011
> >> IPR000477 |Pseudomonas aeruginosa| 9/14/2011
> >> IPR008948 |Pseudomonas aeruginosa| 9/14/2011
> >> IPR005415 |Pseudomonas aeruginosa| 9/14/2011
> >> IPR009651 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> IPR007895 |Pseudomonas aeruginosa| 9/14/2011
> >> IPR008231 |Pseudomonas aeruginosa| 9/14/2011
> >> IPR004558 |Pseudomonas aeruginosa| 9/14/2011
> >> IPR011067 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> IPR006358 |Pseudomonas aeruginosa| 9/14/2011
> >>
> >>
> >> PDB
> >> ID Species Date
> >> 2ZWS |Pseudomonas aeruginosa| 9/14/2011
> >> 2F9I |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> 2EXV |Pseudomonas aeruginosa| 9/14/2011
> >> 3L34 |Pseudomonas aeruginosa| 9/14/2011
> >> 1EZM |Pseudomonas aeruginosa| 9/14/2011
> >> 2WYB |Pseudomonas aeruginosa| 9/14/2011
> >> 2F1L |Pseudomonas aeruginosa| 9/14/2011
> >> 1D7L |Pseudomonas aeruginosa| 9/14/2011
> >> 1Y12 |Pseudomonas aeruginosa| 9/14/2011
> >> 2IXH |Pseudomonas aeruginosa| 9/14/2011
> >> 1XAG |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> 2IXI |Pseudomonas aeruginosa| 9/14/2011
> >>
> >>
> >> EMBL
> >> ID Species Date
> >> AJ003006 |Pseudomonas aeruginosa| 9/14/2011
> >> BX571856 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
> >> AJ633619 |Pseudomonas aeruginosa| 9/14/2011
> >> AJ633602 |Pseudomonas aeruginosa| 9/14/2011
> >> U07359 |Pseudomonas aeruginosa| 9/14/2011
> >> X54201 |Pseudomonas aeruginosa| 9/14/2011
> >> AY899300 |Pseudomonas aeruginosa| 9/14/2011
> >> AB085582 |Pseudomonas aeruginosa| 9/14/2011
> >> AB075926 |Pseudomonas aeruginosa| 9/14/2011
> >> AF306766 |Pseudomonas aeruginosa| 9/14/2011
> >> X99471 |Pseudomonas aeruginosa| 9/14/2011
> >> M21093 |Pseudomonas aeruginosa| 9/14/2011
> >>
> >>
> >> Richard
> >>
> >> On Wed, Sep 14, 2011 at 6:50 PM, Richard Brous <rbr...@gm...>
> wrote:
> >> OK, going to commit my changes to UniProtDatabaseProfile:
> getSystemTableManager()
> >>
> >> Here is some logging info to confirm result.next() within the while loop
> is both id and species name:
> >>
> >> 3070712 [Thread-4] INFO
> edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile
> - getSystemTableManager(): while loop: ID:: IPR006314 Species::
> Staphylococcus aureus (strain MRSA252)
> >> 3070712 [Thread-4] INFO
> edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile
> - getSystemTableManager(): while loop: ID:: IPR013840 Species::
> Staphylococcus aureus (strain MRSA252)
> >> 3070728 [Thread-4] INFO
> edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile
> - getSystemTableManager(): while loop: ID:: IPR015887 Species::
> Pseudomonas aeruginosa
> >> 3070728 [Thread-4] INFO
> edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile
> - getSystemTableManager(): while loop: ID:: IPR016148 Species::
> Pseudomonas aeruginosa
> >>
> >> Richard
> >>
> >> On Wed, Sep 14, 2011 at 3:20 PM, Richard Brous <rbr...@gm...>
> wrote:
> >> Solid progress made and I now have a compilable working copy.
> >>
> >> I'm now working through how to plug the results of the query into the
> proper slots under the while loop. I had stumbled on an error where I was
> supplying the column name instead of the actual data from the tuple. Solved
> that and am hoping the current export will be the last before I commit to
> sourceforge.
> >>
> >> Richard
> >>
> >>
> >> On Mon, Sep 12, 2011 at 10:59 PM, Richard Brous <rbr...@gm...>
> wrote:
> >> Spent the weekend reviewing sql and I have achieved some clarity.
> >>
> >> I'm still working through things but not at least I have better context
> and can ask intelligent questions.
> >>
> >> The sub query was a big help, I'm not sure how long it would have taken
> me to do all the joins using ON to return "hjid | species name"
> >>
> >> Dondi - I'll stop by after theory tomorrow to discuss further.
> >>
> >> Thanks.
> >>
> >> Richard
> >>
> >>
> >> On Thu, Sep 8, 2011 at 5:24 PM, John David N. Dionisio <do...@lm...>
> wrote:
> >> Hi Rich,
> >>
> >> As discussed in our meeting, here is a first step toward the new system
> table query:
> >>
> >> SELECT entrytype.hjid, organismnametype.value FROM entrytype
> INNER JOIN organismtype ON (entrytype.organism = organismtype.hjid) inner
> join organismnametype on (organismtype.hjid =
> organismnametype.organismtype_name_hjid) INNER JOIN dbreferencetype
> ON(dbreferencetype.organismtype_dbreference_hjid = organismtype.hjid) WHERE
> dbreferencetype.type = 'NCBI Taxonomy' and (id = '90371');
> >>
> >> (substitute the "id = " clause accordingly)
> >>
> >> John David N. Dionisio, PhD
> >> Associate Professor, Computer Science
> >> Associate Director, University Honors Program
> >> Loyola Marymount University
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Why Cloud-Based Security and Archiving Make Sense
> >> Osterman Research conducted this study that outlines how and why cloud
> >> computing security and archiving is rapidly being adopted across the IT
> >> space for its ease of implementation, lower cost, and increased
> >> reliability. Learn more.
> http://www.accelacomm.com/jaw/sfnl/114/51425301/
> >> _______________________________________________
> >> xmlpipedb-developer mailing list
> >> xml...@li...
> >> https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
> >>
> >>
> >>
> >>
> >>
> >>
> > <ATT00001..txt><ATT00002..txt>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> xmlpipedb-developer mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
>

Very cool; looks like we can move on now. Dr. Dahlquist and I suspect that the relationship tables may not actually be as hard as they seem; just a matter of tweaking the initial queries (which you're more comfortable doing now!) so that they return the corresponding records for all of the requested species. Onward we go :)
John David N. Dionisio, PhD
Associate Professor, Computer Science
Associate Director, University Honors Program
Loyola Marymount University
On Sep 19, 2011, at 11:09 AM, Kam Dahlquist wrote:
> Hi,
> 
> LMU can accept 20 MB attachments now; I don't know how big your file is zipped, but that's an option. You could also use LionShare.
> 
> Glad to see success!
> 
> Kam
> 
> At 06:05 PM 9/18/2011, you wrote:
>> Tried to post my latest gdb export to the biodb wiki but receiving log in error (per separate email)
>> 
>> But, I wanted to let you know I verified that each improper system table does in fact contain the id and species name (samples of each):
>> 
>> 
>> Pfam 
>> ID Species Date 
>> PF02866 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> PF07050 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> PF03479 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> PF02317 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> PF03279 |Pseudomonas aeruginosa| 9/14/2011 
>> PF09922 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> PF04205 |Pseudomonas aeruginosa| 9/14/2011 
>> PF03379 |Pseudomonas aeruginosa| 9/14/2011 
>> PF05389 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> 
>> 
>> RefSeq 
>> ID Species Date 
>> YP_039973 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> YP_040411 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> YP_039521 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> NP_253798 |Pseudomonas aeruginosa| 9/14/2011 
>> NP_254101 |Pseudomonas aeruginosa| 9/14/2011 
>> NP_248930 |Pseudomonas aeruginosa| 9/14/2011 
>> NP_251503 |Pseudomonas aeruginosa| 9/14/2011 
>> NP_249960 |Pseudomonas aeruginosa| 9/14/2011 
>> NP_253220 |Pseudomonas aeruginosa| 9/14/2011 
>> YP_040877 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> NP_253802 |Pseudomonas aeruginosa| 9/14/2011 
>> 
>> 
>> GeneId 
>> ID Species Date 
>> 879140 |Pseudomonas aeruginosa| 9/14/2011 
>> 2859243 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> 879337 |Pseudomonas aeruginosa| 9/14/2011 
>> 2860668 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> 881899 |Pseudomonas aeruginosa| 9/14/2011 
>> 882312 |Pseudomonas aeruginosa| 9/14/2011 
>> 2860009 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> 881520 |Pseudomonas aeruginosa| 9/14/2011 
>> 2861152 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> 881596 |Pseudomonas aeruginosa| 9/14/2011 
>> 
>> 
>> InterPro 
>> ID Species Date 
>> IPR022522 |Pseudomonas aeruginosa| 9/14/2011 
>> IPR003538 |Pseudomonas aeruginosa| 9/14/2011 
>> IPR016379 |Pseudomonas aeruginosa| 9/14/2011 
>> IPR016920 |Pseudomonas aeruginosa| 9/14/2011 
>> IPR000477 |Pseudomonas aeruginosa| 9/14/2011 
>> IPR008948 |Pseudomonas aeruginosa| 9/14/2011 
>> IPR005415 |Pseudomonas aeruginosa| 9/14/2011 
>> IPR009651 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> IPR007895 |Pseudomonas aeruginosa| 9/14/2011 
>> IPR008231 |Pseudomonas aeruginosa| 9/14/2011 
>> IPR004558 |Pseudomonas aeruginosa| 9/14/2011 
>> IPR011067 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> IPR006358 |Pseudomonas aeruginosa| 9/14/2011 
>> 
>> 
>> PDB 
>> ID Species Date 
>> 2ZWS |Pseudomonas aeruginosa| 9/14/2011 
>> 2F9I |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> 2EXV |Pseudomonas aeruginosa| 9/14/2011 
>> 3L34 |Pseudomonas aeruginosa| 9/14/2011 
>> 1EZM |Pseudomonas aeruginosa| 9/14/2011 
>> 2WYB |Pseudomonas aeruginosa| 9/14/2011 
>> 2F1L |Pseudomonas aeruginosa| 9/14/2011 
>> 1D7L |Pseudomonas aeruginosa| 9/14/2011 
>> 1Y12 |Pseudomonas aeruginosa| 9/14/2011 
>> 2IXH |Pseudomonas aeruginosa| 9/14/2011 
>> 1XAG |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> 2IXI |Pseudomonas aeruginosa| 9/14/2011 
>> 
>> 
>> EMBL 
>> ID Species Date 
>> AJ003006 |Pseudomonas aeruginosa| 9/14/2011 
>> BX571856 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 
>> AJ633619 |Pseudomonas aeruginosa| 9/14/2011 
>> AJ633602 |Pseudomonas aeruginosa| 9/14/2011 
>> U07359 |Pseudomonas aeruginosa| 9/14/2011 
>> X54201 |Pseudomonas aeruginosa| 9/14/2011 
>> AY899300 |Pseudomonas aeruginosa| 9/14/2011 
>> AB085582 |Pseudomonas aeruginosa| 9/14/2011 
>> AB075926 |Pseudomonas aeruginosa| 9/14/2011 
>> AF306766 |Pseudomonas aeruginosa| 9/14/2011 
>> X99471 |Pseudomonas aeruginosa| 9/14/2011 
>> M21093 |Pseudomonas aeruginosa| 9/14/2011 
>> 
>> 
>> Richard
>> 
>> On Wed, Sep 14, 2011 at 6:50 PM, Richard Brous <rbr...@gm...> wrote:
>> OK, going to commit my changes to UniProtDatabaseProfile: getSystemTableManager()
>> 
>> Here is some logging info to confirm result.next() within the while loop is both id and species name:
>> 
>> 3070712 [Thread-4] INFO edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile - getSystemTableManager(): while loop: ID:: IPR006314 Species:: Staphylococcus aureus (strain MRSA252)
>> 3070712 [Thread-4] INFO edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile - getSystemTableManager(): while loop: ID:: IPR013840 Species:: Staphylococcus aureus (strain MRSA252)
>> 3070728 [Thread-4] INFO edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile - getSystemTableManager(): while loop: ID:: IPR015887 Species:: Pseudomonas aeruginosa
>> 3070728 [Thread-4] INFO edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile - getSystemTableManager(): while loop: ID:: IPR016148 Species:: Pseudomonas aeruginosa
>> 
>> Richard
>> 
>> On Wed, Sep 14, 2011 at 3:20 PM, Richard Brous <rbr...@gm...> wrote:
>> Solid progress made and I now have a compilable working copy. 
>> 
>> I'm now working through how to plug the results of the query into the proper slots under the while loop. I had stumbled on an error where I was supplying the column name instead of the actual data from the tuple. Solved that and am hoping the current export will be the last before I commit to sourceforge.
>> 
>> Richard
>> 
>> 
>> On Mon, Sep 12, 2011 at 10:59 PM, Richard Brous <rbr...@gm...> wrote:
>> Spent the weekend reviewing sql and I have achieved some clarity. 
>> 
>> I'm still working through things but not at least I have better context and can ask intelligent questions.
>> 
>> The sub query was a big help, I'm not sure how long it would have taken me to do all the joins using ON to return "hjid | species name" 
>> 
>> Dondi - I'll stop by after theory tomorrow to discuss further.
>> 
>> Thanks.
>> 
>> Richard 
>> 
>> 
>> On Thu, Sep 8, 2011 at 5:24 PM, John David N. Dionisio <do...@lm...> wrote:
>> Hi Rich,
>> 
>> As discussed in our meeting, here is a first step toward the new system table query:
>> 
>> SELECT entrytype.hjid, organismnametype.value FROM entrytype INNER JOIN organismtype ON (entrytype.organism = organismtype.hjid) inner join organismnametype on (organismtype.hjid = organismnametype.organismtype_name_hjid) INNER JOIN dbreferencetype ON(dbreferencetype.organismtype_dbreference_hjid = organismtype.hjid) WHERE dbreferencetype.type = 'NCBI Taxonomy' and (id = '90371');
>> 
>> (substitute the "id = " clause accordingly)
>> 
>> John David N. Dionisio, PhD
>> Associate Professor, Computer Science
>> Associate Director, University Honors Program
>> Loyola Marymount University
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Why Cloud-Based Security and Archiving Make Sense
>> Osterman Research conducted this study that outlines how and why cloud
>> computing security and archiving is rapidly being adopted across the IT
>> space for its ease of implementation, lower cost, and increased
>> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
>> _______________________________________________
>> xmlpipedb-developer mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
>> 
>> 
>> 
>> 
>> 
>> 
> <ATT00001..txt><ATT00002..txt>

Hi,
LMU can accept 20 MB attachments now; I don't know how big your file 
is zipped, but that's an option. You could also use LionShare.
Glad to see success!
Kam
At 06:05 PM 9/18/2011, you wrote:
>Tried to post my latest gdb export to the biodb wiki but receiving 
>log in error (per separate email)
>
>But, I wanted to let you know I verified that each improper system 
>table does in fact contain the id and species name (samples of each):
>
>
>Pfam
>ID Species Date
>PF02866 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>PF07050 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>PF03479 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>PF02317 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>PF03279 |Pseudomonas aeruginosa| 9/14/2011
>PF09922 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>PF04205 |Pseudomonas aeruginosa| 9/14/2011
>PF03379 |Pseudomonas aeruginosa| 9/14/2011
>PF05389 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>
>
>RefSeq
>ID Species Date
>YP_039973 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>YP_040411 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>YP_039521 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>NP_253798 |Pseudomonas aeruginosa| 9/14/2011
>NP_254101 |Pseudomonas aeruginosa| 9/14/2011
>NP_248930 |Pseudomonas aeruginosa| 9/14/2011
>NP_251503 |Pseudomonas aeruginosa| 9/14/2011
>NP_249960 |Pseudomonas aeruginosa| 9/14/2011
>NP_253220 |Pseudomonas aeruginosa| 9/14/2011
>YP_040877 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>NP_253802 |Pseudomonas aeruginosa| 9/14/2011
>
>
>GeneId
>ID Species Date
>879140 |Pseudomonas aeruginosa| 9/14/2011
>2859243 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>879337 |Pseudomonas aeruginosa| 9/14/2011
>2860668 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>881899 |Pseudomonas aeruginosa| 9/14/2011
>882312 |Pseudomonas aeruginosa| 9/14/2011
>2860009 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>881520 |Pseudomonas aeruginosa| 9/14/2011
>2861152 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>881596 |Pseudomonas aeruginosa| 9/14/2011
>
>
>InterPro
>ID Species Date
>IPR022522 |Pseudomonas aeruginosa| 9/14/2011
>IPR003538 |Pseudomonas aeruginosa| 9/14/2011
>IPR016379 |Pseudomonas aeruginosa| 9/14/2011
>IPR016920 |Pseudomonas aeruginosa| 9/14/2011
>IPR000477 |Pseudomonas aeruginosa| 9/14/2011
>IPR008948 |Pseudomonas aeruginosa| 9/14/2011
>IPR005415 |Pseudomonas aeruginosa| 9/14/2011
>IPR009651 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>IPR007895 |Pseudomonas aeruginosa| 9/14/2011
>IPR008231 |Pseudomonas aeruginosa| 9/14/2011
>IPR004558 |Pseudomonas aeruginosa| 9/14/2011
>IPR011067 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>IPR006358 |Pseudomonas aeruginosa| 9/14/2011
>
>
>PDB
>ID Species Date
>2ZWS |Pseudomonas aeruginosa| 9/14/2011
>2F9I |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>2EXV |Pseudomonas aeruginosa| 9/14/2011
>3L34 |Pseudomonas aeruginosa| 9/14/2011
>1EZM |Pseudomonas aeruginosa| 9/14/2011
>2WYB |Pseudomonas aeruginosa| 9/14/2011
>2F1L |Pseudomonas aeruginosa| 9/14/2011
>1D7L |Pseudomonas aeruginosa| 9/14/2011
>1Y12 |Pseudomonas aeruginosa| 9/14/2011
>2IXH |Pseudomonas aeruginosa| 9/14/2011
>1XAG |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>2IXI |Pseudomonas aeruginosa| 9/14/2011
>
>
>EMBL
>ID Species Date
>AJ003006 |Pseudomonas aeruginosa| 9/14/2011
>BX571856 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
>AJ633619 |Pseudomonas aeruginosa| 9/14/2011
>AJ633602 |Pseudomonas aeruginosa| 9/14/2011
>U07359 |Pseudomonas aeruginosa| 9/14/2011
>X54201 |Pseudomonas aeruginosa| 9/14/2011
>AY899300 |Pseudomonas aeruginosa| 9/14/2011
>AB085582 |Pseudomonas aeruginosa| 9/14/2011
>AB075926 |Pseudomonas aeruginosa| 9/14/2011
>AF306766 |Pseudomonas aeruginosa| 9/14/2011
>X99471 |Pseudomonas aeruginosa| 9/14/2011
>M21093 |Pseudomonas aeruginosa| 9/14/2011
>
>
>Richard
>
>On Wed, Sep 14, 2011 at 6:50 PM, Richard Brous 
><<mailto:rbr...@gm...>rbr...@gm...> wrote:
>OK, going to commit my changes to UniProtDatabaseProfile: 
>getSystemTableManager()
>
>Here is some logging info to confirm result.next() within the while 
>loop is both id and species name:
>
>3070712 [Thread-4] 
>INFO 
>edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile 
>- getSystemTableManager(): while loop: ID:: IPR006314 Species:: 
>Staphylococcus aureus (strain MRSA252)
>3070712 [Thread-4] 
>INFO 
>edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile 
>- getSystemTableManager(): while loop: ID:: IPR013840 Species:: 
>Staphylococcus aureus (strain MRSA252)
>3070728 [Thread-4] 
>INFO 
>edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile 
>- getSystemTableManager(): while loop: ID:: IPR015887 Species:: 
>Pseudomonas aeruginosa
>3070728 [Thread-4] 
>INFO 
>edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile 
>- getSystemTableManager(): while loop: ID:: IPR016148 Species:: 
>Pseudomonas aeruginosa
>
>Richard
>
>On Wed, Sep 14, 2011 at 3:20 PM, Richard Brous 
><<mailto:rbr...@gm...>rbr...@gm...> wrote:
>Solid progress made and I now have a compilable working copy.
>
>I'm now working through how to plug the results of the query into 
>the proper slots under the while loop. I had stumbled on an error 
>where I was supplying the column name instead of the actual data 
>from the tuple. Solved that and am hoping the current export will be 
>the last before I commit to sourceforge.
>
>Richard
>
>
>On Mon, Sep 12, 2011 at 10:59 PM, Richard Brous 
><<mailto:rbr...@gm...>rbr...@gm...> wrote:
>Spent the weekend reviewing sql and I have achieved some clarity.
>
>I'm still working through things but not at least I have better 
>context and can ask intelligent questions.
>
>The sub query was a big help, I'm not sure how long it would have 
>taken me to do all the joins using ON to return "hjid | species name"
>
>Dondi - I'll stop by after theory tomorrow to discuss further.
>
>Thanks.
>
>Richard
>
>
>On Thu, Sep 8, 2011 at 5:24 PM, John David N. Dionisio 
><<mailto:do...@lm...>do...@lm...> wrote:
>Hi Rich,
>
>As discussed in our meeting, here is a first step toward the new 
>system table query:
>
> SELECT entrytype.hjid, organismnametype.value FROM entrytype 
> INNER JOIN organismtype ON (entrytype.organism = organismtype.hjid) 
> inner join organismnametype on (organismtype.hjid = 
> organismnametype.organismtype_name_hjid) INNER JOIN dbreferencetype 
> ON(dbreferencetype.organismtype_dbreference_hjid = 
> organismtype.hjid) WHERE dbreferencetype.type = 'NCBI Taxonomy' and 
> (id = '90371');
>
>(substitute the "id = " clause accordingly)
>
>John David N. Dionisio, PhD
>Associate Professor, Computer Science
>Associate Director, University Honors Program
>Loyola Marymount University
>
>
>
>
>------------------------------------------------------------------------------
>Why Cloud-Based Security and Archiving Make Sense
>Osterman Research conducted this study that outlines how and why cloud
>computing security and archiving is rapidly being adopted across the IT
>space for its ease of implementation, lower cost, and increased
>reliability. Learn more. 
><http://www.accelacomm.com/jaw/sfnl/114/51425301/>http://www.accelacomm.com/jaw/sfnl/114/51425301/
>_______________________________________________
>xmlpipedb-developer mailing list
><mailto:xml...@li...>xml...@li...
>https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
>
>
>
>
>
>

Tried to post my latest gdb export to the biodb wiki but receiving log in
error (per separate email)
But, I wanted to let you know I verified that each improper system table
does in fact contain the id and species name (samples of each):
*Pfam* ID Species Date PF02866 |Staphylococcus aureus (strain MRSA252)|
9/14/2011 PF07050 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
PF03479 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 PF02317
|Staphylococcus
aureus (strain MRSA252)| 9/14/2011 PF03279 |Pseudomonas aeruginosa|
9/14/2011 PF09922 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
PF04205 |Pseudomonas aeruginosa| 9/14/2011 PF03379 |Pseudomonas aeruginosa|
9/14/2011 PF05389 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
*RefSeq* ID Species Date YP_039973 |Staphylococcus aureus (strain
MRSA252)| 9/14/2011 YP_040411 |Staphylococcus aureus (strain MRSA252)|
9/14/2011 YP_039521 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
NP_253798 |Pseudomonas aeruginosa| 9/14/2011 NP_254101 |Pseudomonas
aeruginosa| 9/14/2011 NP_248930 |Pseudomonas aeruginosa| 9/14/2011
NP_251503 |Pseudomonas aeruginosa| 9/14/2011 NP_249960 |Pseudomonas
aeruginosa| 9/14/2011 NP_253220 |Pseudomonas aeruginosa| 9/14/2011
YP_040877 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
NP_253802 |Pseudomonas
aeruginosa| 9/14/2011
*GeneId* ID Species Date 879140 |Pseudomonas aeruginosa| 9/14/2011
2859243 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 879337 |Pseudomonas
aeruginosa| 9/14/2011 2860668 |Staphylococcus aureus (strain MRSA252)|
9/14/2011 881899 |Pseudomonas aeruginosa| 9/14/2011 882312 |Pseudomonas
aeruginosa| 9/14/2011 2860009 |Staphylococcus aureus (strain MRSA252)|
9/14/2011 881520 |Pseudomonas aeruginosa| 9/14/2011 2861152 |Staphylococcus
aureus (strain MRSA252)| 9/14/2011 881596 |Pseudomonas aeruginosa|
9/14/2011
*InterPro* ID Species Date IPR022522 |Pseudomonas aeruginosa| 9/14/2011
IPR003538 |Pseudomonas aeruginosa| 9/14/2011 IPR016379 |Pseudomonas
aeruginosa| 9/14/2011 IPR016920 |Pseudomonas aeruginosa| 9/14/2011
IPR000477 |Pseudomonas aeruginosa| 9/14/2011 IPR008948 |Pseudomonas
aeruginosa| 9/14/2011 IPR005415 |Pseudomonas aeruginosa| 9/14/2011
IPR009651 |Staphylococcus aureus (strain MRSA252)| 9/14/2011
IPR007895 |Pseudomonas
aeruginosa| 9/14/2011 IPR008231 |Pseudomonas aeruginosa| 9/14/2011
IPR004558 |Pseudomonas aeruginosa| 9/14/2011 IPR011067 |Staphylococcus
aureus (strain MRSA252)| 9/14/2011 IPR006358 |Pseudomonas aeruginosa|
9/14/2011
*PDB* ID Species Date 2ZWS |Pseudomonas aeruginosa| 9/14/2011 2F9I
|Staphylococcus
aureus (strain MRSA252)| 9/14/2011 2EXV |Pseudomonas aeruginosa| 9/14/2011
3L34 |Pseudomonas aeruginosa| 9/14/2011 1EZM |Pseudomonas aeruginosa|
9/14/2011 2WYB |Pseudomonas aeruginosa| 9/14/2011 2F1L |Pseudomonas
aeruginosa| 9/14/2011 1D7L |Pseudomonas aeruginosa| 9/14/2011 1Y12
|Pseudomonas
aeruginosa| 9/14/2011 2IXH |Pseudomonas aeruginosa| 9/14/2011 1XAG
|Staphylococcus
aureus (strain MRSA252)| 9/14/2011 2IXI |Pseudomonas aeruginosa| 9/14/2011
*EMBL* ID Species Date AJ003006 |Pseudomonas aeruginosa| 9/14/2011
BX571856 |Staphylococcus aureus (strain MRSA252)| 9/14/2011 AJ633619
|Pseudomonas
aeruginosa| 9/14/2011 AJ633602 |Pseudomonas aeruginosa| 9/14/2011
U07359 |Pseudomonas
aeruginosa| 9/14/2011 X54201 |Pseudomonas aeruginosa| 9/14/2011
AY899300 |Pseudomonas
aeruginosa| 9/14/2011 AB085582 |Pseudomonas aeruginosa| 9/14/2011
AB075926 |Pseudomonas
aeruginosa| 9/14/2011 AF306766 |Pseudomonas aeruginosa| 9/14/2011
X99471 |Pseudomonas
aeruginosa| 9/14/2011 M21093 |Pseudomonas aeruginosa| 9/14/2011
Richard
On Wed, Sep 14, 2011 at 6:50 PM, Richard Brous <rbr...@gm...> wrote:
> OK, going to commit my changes to UniProtDatabaseProfile:
> getSystemTableManager()
>
> Here is some logging info to confirm result.next() within the while loop is
> both id and species name:
>
> 3070712 [Thread-4] INFO
> edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile
> - getSystemTableManager(): while loop: ID:: IPR006314 Species::
> Staphylococcus aureus (strain MRSA252)
> 3070712 [Thread-4] INFO
> edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile
> - getSystemTableManager(): while loop: ID:: IPR013840 Species::
> Staphylococcus aureus (strain MRSA252)
> 3070728 [Thread-4] INFO
> edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile
> - getSystemTableManager(): while loop: ID:: IPR015887 Species::
> Pseudomonas aeruginosa
> 3070728 [Thread-4] INFO
> edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile
> - getSystemTableManager(): while loop: ID:: IPR016148 Species::
> Pseudomonas aeruginosa
>
> Richard
>
> On Wed, Sep 14, 2011 at 3:20 PM, Richard Brous <rbr...@gm...> wrote:
>
>> Solid progress made and I now have a compilable working copy.
>>
>> I'm now working through how to plug the results of the query into the
>> proper slots under the while loop. I had stumbled on an error where I was
>> supplying the column name instead of the actual data from the tuple. Solved
>> that and am hoping the current export will be the last before I commit to
>> sourceforge.
>>
>> Richard
>>
>>
>> On Mon, Sep 12, 2011 at 10:59 PM, Richard Brous <rbr...@gm...>wrote:
>>
>>> Spent the weekend reviewing sql and I have achieved some clarity.
>>>
>>> I'm still working through things but not at least I have better context
>>> and can ask intelligent questions.
>>>
>>> The sub query was a big help, I'm not sure how long it would have taken
>>> me to do all the joins using ON to return "hjid | species name"
>>>
>>> Dondi - I'll stop by after theory tomorrow to discuss further.
>>>
>>> Thanks.
>>>
>>> Richard
>>>
>>>
>>> On Thu, Sep 8, 2011 at 5:24 PM, John David N. Dionisio <do...@lm...>wrote:
>>>
>>>> Hi Rich,
>>>>
>>>> As discussed in our meeting, here is a first step toward the new system
>>>> table query:
>>>>
>>>> SELECT entrytype.hjid, organismnametype.value FROM entrytype
>>>> INNER JOIN organismtype ON (entrytype.organism = organismtype.hjid) inner
>>>> join organismnametype on (organismtype.hjid =
>>>> organismnametype.organismtype_name_hjid) INNER JOIN dbreferencetype
>>>> ON(dbreferencetype.organismtype_dbreference_hjid = organismtype.hjid) WHERE
>>>> dbreferencetype.type = 'NCBI Taxonomy' and (id = '90371');
>>>>
>>>> (substitute the "id = " clause accordingly)
>>>>
>>>> John David N. Dionisio, PhD
>>>> Associate Professor, Computer Science
>>>> Associate Director, University Honors Program
>>>> Loyola Marymount University
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Why Cloud-Based Security and Archiving Make Sense
>>>> Osterman Research conducted this study that outlines how and why cloud
>>>> computing security and archiving is rapidly being adopted across the IT
>>>> space for its ease of implementation, lower cost, and increased
>>>> reliability. Learn more.
>>>> http://www.accelacomm.com/jaw/sfnl/114/51425301/
>>>> _______________________________________________
>>>> xmlpipedb-developer mailing list
>>>> xml...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
>>>>
>>>
>>>
>>
>

OK, going to commit my changes to UniProtDatabaseProfile:
getSystemTableManager()
Here is some logging info to confirm result.next() within the while loop is
both id and species name:
3070712 [Thread-4] INFO
 edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile
 - getSystemTableManager(): while loop: ID:: IPR006314 Species::
Staphylococcus aureus (strain MRSA252)
3070712 [Thread-4] INFO
 edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile
 - getSystemTableManager(): while loop: ID:: IPR013840 Species::
Staphylococcus aureus (strain MRSA252)
3070728 [Thread-4] INFO
 edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile
 - getSystemTableManager(): while loop: ID:: IPR015887 Species::
Pseudomonas aeruginosa
3070728 [Thread-4] INFO
 edu.lmu.xmlpipedb.gmbuilder.databasetoolkit.profiles.UniProtDatabaseProfile
 - getSystemTableManager(): while loop: ID:: IPR016148 Species::
Pseudomonas aeruginosa
Richard
On Wed, Sep 14, 2011 at 3:20 PM, Richard Brous <rbr...@gm...> wrote:
> Solid progress made and I now have a compilable working copy.
>
> I'm now working through how to plug the results of the query into the
> proper slots under the while loop. I had stumbled on an error where I was
> supplying the column name instead of the actual data from the tuple. Solved
> that and am hoping the current export will be the last before I commit to
> sourceforge.
>
> Richard
>
>
> On Mon, Sep 12, 2011 at 10:59 PM, Richard Brous <rbr...@gm...>wrote:
>
>> Spent the weekend reviewing sql and I have achieved some clarity.
>>
>> I'm still working through things but not at least I have better context
>> and can ask intelligent questions.
>>
>> The sub query was a big help, I'm not sure how long it would have taken me
>> to do all the joins using ON to return "hjid | species name"
>>
>> Dondi - I'll stop by after theory tomorrow to discuss further.
>>
>> Thanks.
>>
>> Richard
>>
>>
>> On Thu, Sep 8, 2011 at 5:24 PM, John David N. Dionisio <do...@lm...>wrote:
>>
>>> Hi Rich,
>>>
>>> As discussed in our meeting, here is a first step toward the new system
>>> table query:
>>>
>>> SELECT entrytype.hjid, organismnametype.value FROM entrytype INNER
>>> JOIN organismtype ON (entrytype.organism = organismtype.hjid) inner join
>>> organismnametype on (organismtype.hjid =
>>> organismnametype.organismtype_name_hjid) INNER JOIN dbreferencetype
>>> ON(dbreferencetype.organismtype_dbreference_hjid = organismtype.hjid) WHERE
>>> dbreferencetype.type = 'NCBI Taxonomy' and (id = '90371');
>>>
>>> (substitute the "id = " clause accordingly)
>>>
>>> John David N. Dionisio, PhD
>>> Associate Professor, Computer Science
>>> Associate Director, University Honors Program
>>> Loyola Marymount University
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Why Cloud-Based Security and Archiving Make Sense
>>> Osterman Research conducted this study that outlines how and why cloud
>>> computing security and archiving is rapidly being adopted across the IT
>>> space for its ease of implementation, lower cost, and increased
>>> reliability. Learn more.
>>> http://www.accelacomm.com/jaw/sfnl/114/51425301/
>>> _______________________________________________
>>> xmlpipedb-developer mailing list
>>> xml...@li...
>>> https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
>>>
>>
>>
>

Solid progress made and I now have a compilable working copy.
I'm now working through how to plug the results of the query into the proper
slots under the while loop. I had stumbled on an error where I was supplying
the column name instead of the actual data from the tuple. Solved that and
am hoping the current export will be the last before I commit to
sourceforge.
Richard
On Mon, Sep 12, 2011 at 10:59 PM, Richard Brous <rbr...@gm...> wrote:
> Spent the weekend reviewing sql and I have achieved some clarity.
>
> I'm still working through things but not at least I have better context and
> can ask intelligent questions.
>
> The sub query was a big help, I'm not sure how long it would have taken me
> to do all the joins using ON to return "hjid | species name"
>
> Dondi - I'll stop by after theory tomorrow to discuss further.
>
> Thanks.
>
> Richard
>
>
> On Thu, Sep 8, 2011 at 5:24 PM, John David N. Dionisio <do...@lm...>wrote:
>
>> Hi Rich,
>>
>> As discussed in our meeting, here is a first step toward the new system
>> table query:
>>
>> SELECT entrytype.hjid, organismnametype.value FROM entrytype INNER
>> JOIN organismtype ON (entrytype.organism = organismtype.hjid) inner join
>> organismnametype on (organismtype.hjid =
>> organismnametype.organismtype_name_hjid) INNER JOIN dbreferencetype
>> ON(dbreferencetype.organismtype_dbreference_hjid = organismtype.hjid) WHERE
>> dbreferencetype.type = 'NCBI Taxonomy' and (id = '90371');
>>
>> (substitute the "id = " clause accordingly)
>>
>> John David N. Dionisio, PhD
>> Associate Professor, Computer Science
>> Associate Director, University Honors Program
>> Loyola Marymount University
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Why Cloud-Based Security and Archiving Make Sense
>> Osterman Research conducted this study that outlines how and why cloud
>> computing security and archiving is rapidly being adopted across the IT
>> space for its ease of implementation, lower cost, and increased
>> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
>> _______________________________________________
>> xmlpipedb-developer mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
>>
>
>

Spent the weekend reviewing sql and I have achieved some clarity.
I'm still working through things but not at least I have better context and
can ask intelligent questions.
The sub query was a big help, I'm not sure how long it would have taken me
to do all the joins using ON to return "hjid | species name"
Dondi - I'll stop by after theory tomorrow to discuss further.
Thanks.
Richard
On Thu, Sep 8, 2011 at 5:24 PM, John David N. Dionisio <do...@lm...>wrote:
> Hi Rich,
>
> As discussed in our meeting, here is a first step toward the new system
> table query:
>
> SELECT entrytype.hjid, organismnametype.value FROM entrytype INNER
> JOIN organismtype ON (entrytype.organism = organismtype.hjid) inner join
> organismnametype on (organismtype.hjid =
> organismnametype.organismtype_name_hjid) INNER JOIN dbreferencetype
> ON(dbreferencetype.organismtype_dbreference_hjid = organismtype.hjid) WHERE
> dbreferencetype.type = 'NCBI Taxonomy' and (id = '90371');
>
> (substitute the "id = " clause accordingly)
>
> John David N. Dionisio, PhD
> Associate Professor, Computer Science
> Associate Director, University Honors Program
> Loyola Marymount University
>
>
>
>
>
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how and why cloud
> computing security and archiving is rapidly being adopted across the IT
> space for its ease of implementation, lower cost, and increased
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> xmlpipedb-developer mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
>

Hi Rich,
As discussed in our meeting, here is a first step toward the new system table query:
	SELECT entrytype.hjid, organismnametype.value FROM entrytype INNER JOIN organismtype ON (entrytype.organism = organismtype.hjid) inner join organismnametype on (organismtype.hjid = organismnametype.organismtype_name_hjid) INNER JOIN dbreferencetype ON(dbreferencetype.organismtype_dbreference_hjid = organismtype.hjid) WHERE dbreferencetype.type = 'NCBI Taxonomy' and (id = '90371'); 
(substitute the "id = " clause accordingly)
John David N. Dionisio, PhD
Associate Professor, Computer Science
Associate Director, University Honors Program
Loyola Marymount University

Good to hear it worked! That was an interesting code journey :) Let me know how the new IDs + species name SQL query goes when you get to it.
John David N. Dionisio, PhD
Associate Professor, Computer Science
Associate Director, University Honors Program
Loyola Marymount University
On Sep 4, 2011, at 5:45 PM, Richard Brous wrote:
> ok, performed a two species export and the info table now contains only two species names in the form:
> 
> species1|species2
> 
> Looks good.
> 
> Richard
> 
> On Sun, Sep 4, 2011 at 12:45 PM, Richard Brous <rbr...@gm...> wrote:
> Thanks for sourcing this... I hadn't had any luck in doing so.
> 
> Compiled and running a test export now before I head to the beach.
> 
> Will let you know how it goes.
> 
> Richard
> 
> On Sun, Sep 4, 2011 at 12:25 AM, John David N. Dionisio <do...@lm...> wrote:
> Hi Rich,
> 
> I took a look at the getInfoTableManager code and may have located the problem. I committed the possible fix, with a comment above it explaining why. Next time you do an export, keep an eye on that species name when more than one species is selected and report back as needed.
> 
> John David N. Dionisio, PhD
> Associate Professor, Computer Science
> Associate Director, University Honors Program
> Loyola Marymount University
> 
> 
> 
> On Sep 2, 2011, at 11:21 AM, Richard Brous wrote:
> 
> > roger, thanks.
> >
> > richard
> >
> > On Fri, Sep 2, 2011 at 11:10 AM, John David N. Dionisio <do...@lm...> wrote:
> > OK, thanks. I will look into issue #1 concurrently and will report back. Regarding issue #2, I confirmed with Kam that we do need the per-species value for each ID. As we are prioritizing database approaches first, here you have a distinct exercise in SQL formation that is relevant to the tutorial course:
> >
> > - Modify the formed query so that it returns, for each ID, the corresponding species name. If successful, you will then have both ID and species name to provide to tableManager.submit, and you will not need an outer loop for every species profile.
> >
> > The way I suggest you do this is to form a valid query directly in PostgreSQL (i.e., via pgAdmin or psql). That should be pretty easy to get since you are logging the final query string --- just copy and paste that. Experiment with the query directly within PostgreSQL until you have one that works. Then transplant that into the code.
> >
> > John David N. Dionisio, PhD
> > Associate Professor, Computer Science
> > Associate Director, University Honors Program
> > Loyola Marymount University
> >
> >
> >
> > On Sep 2, 2011, at 11:04 AM, Richard Brous wrote:
> >
> > > OK, so still two outstanding issues regarding the last 2 modified methods:
> > >
> > > 1. getInfoTableManager()
> > >
> > > Still returning 3 species names when only two are selected. Returns one species name when only one is selected.
> > > - I will review the loop again and see if I can determine what is going on here.
> > >
> > > 2. getSystemTableManager()
> > >
> > > I added a for loop within the while condition which after discussions we know is incorrect. Will pull that out but we need to determine how to move forward with the issue of determining which species each id belongs to. removed loop and submitted to SourceForge but now build is essentially broken till we figure out the wrinkle. Adding a for speciesprofile loop at the top was discussed as a solution of last resort.
> > >
> > > UniProtDatabaseProfile - while loop begins at line # 585
> > >
> > > ---------------------------------------------------------------------------------------------------------------
> > >
> > > Also made modifications to getSystemsTableManager() which applies the species customizations for each species profile selected. Seems correct to me but please confirm.
> > >
> > > --------------------------------------------------------------------------------------------------------------
> > >
> > > Discussions surrounding getPrimarySystemTableManager() assumed likely bad coding since it seems to call for a customized schema although it is identical to the default UniProt schema.
> > >
> > > It calls getPrimarySystemTableManagerCustomizations() which is specific to Arabidopsis thaliana and Ecoli only.
> > >
> > > Didn't want to dig into this yet until other higher priority modifications were done first plus I believe a discussion with Dr. D was going to occur as well.
> > >
> > > ---------------------------------------------------------------------------------------------------------------
> > >
> > > getRelationsTableManager() is the last method which remains untouched but I will start reviewing and come up with a plan of attack.
> > >
> > > --------------------------------------------------------------------------------------------------------------
> > >
> > > These are all the loose ends I can think of to document.
> > >
> > > Thanks!
> > >
> > > Richard
> > >
> > >
> > >
> > > On Wed, Aug 31, 2011 at 12:52 PM, Richard Brous <rbr...@gm...> wrote:
> > > Submitted changes to UniProtDatabaseProfile based on the logical corrections from yesterdays convo with Dondi.
> > >
> > > These do not yet include the discussed optimizations, just wanted to get it working and do some test exports... which completed successfully.
> > >
> > > I also added a for loop under the while loop in getSystemTableManager() to ensure each query result is processed for each selected species profile.
> > > The loop is on line 587 and I added it because it seemed a solution to have each species profile included... is this correct or should I be submitting all at once versus each species?
> > >
> > > Richard
> > >
> > > <ATT00001..txt><ATT00002..txt>
> >
> >
> > ------------------------------------------------------------------------------
> > Special Offer -- Download ArcSight Logger for FREE!
> > Finally, a world-class log management solution at an even better
> > price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> > download Logger. Secure your free ArcSight Logger TODAY!
> > http://p.sf.net/sfu/arcsisghtdev2dev
> > _______________________________________________
> > xmlpipedb-developer mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
> >
> > <ATT00001..txt><ATT00002..txt>
> 
> 
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> xmlpipedb-developer mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
> 
> 
> <ATT00001..txt><ATT00002..txt>

ok, performed a two species export and the info table now contains only two
species names in the form:
species1|species2
Looks good.
Richard
On Sun, Sep 4, 2011 at 12:45 PM, Richard Brous <rbr...@gm...> wrote:
> Thanks for sourcing this... I hadn't had any luck in doing so.
>
> Compiled and running a test export now before I head to the beach.
>
> Will let you know how it goes.
>
> Richard
>
> On Sun, Sep 4, 2011 at 12:25 AM, John David N. Dionisio <do...@lm...>wrote:
>
>> Hi Rich,
>>
>> I took a look at the getInfoTableManager code and may have located the
>> problem. I committed the possible fix, with a comment above it explaining
>> why. Next time you do an export, keep an eye on that species name when more
>> than one species is selected and report back as needed.
>>
>> John David N. Dionisio, PhD
>> Associate Professor, Computer Science
>> Associate Director, University Honors Program
>> Loyola Marymount University
>>
>>
>>
>> On Sep 2, 2011, at 11:21 AM, Richard Brous wrote:
>>
>> > roger, thanks.
>> >
>> > richard
>> >
>> > On Fri, Sep 2, 2011 at 11:10 AM, John David N. Dionisio <do...@lm...>
>> wrote:
>> > OK, thanks. I will look into issue #1 concurrently and will report
>> back. Regarding issue #2, I confirmed with Kam that we do need the
>> per-species value for each ID. As we are prioritizing database approaches
>> first, here you have a distinct exercise in SQL formation that is relevant
>> to the tutorial course:
>> >
>> > - Modify the formed query so that it returns, for each ID, the
>> corresponding species name. If successful, you will then have both ID and
>> species name to provide to tableManager.submit, and you will not need an
>> outer loop for every species profile.
>> >
>> > The way I suggest you do this is to form a valid query directly in
>> PostgreSQL (i.e., via pgAdmin or psql). That should be pretty easy to get
>> since you are logging the final query string --- just copy and paste that.
>> Experiment with the query directly within PostgreSQL until you have one
>> that works. Then transplant that into the code.
>> >
>> > John David N. Dionisio, PhD
>> > Associate Professor, Computer Science
>> > Associate Director, University Honors Program
>> > Loyola Marymount University
>> >
>> >
>> >
>> > On Sep 2, 2011, at 11:04 AM, Richard Brous wrote:
>> >
>> > > OK, so still two outstanding issues regarding the last 2 modified
>> methods:
>> > >
>> > > 1. getInfoTableManager()
>> > >
>> > > Still returning 3 species names when only two are selected. Returns
>> one species name when only one is selected.
>> > > - I will review the loop again and see if I can determine what is
>> going on here.
>> > >
>> > > 2. getSystemTableManager()
>> > >
>> > > I added a for loop within the while condition which after discussions
>> we know is incorrect. Will pull that out but we need to determine how to
>> move forward with the issue of determining which species each id belongs to.
>> removed loop and submitted to SourceForge but now build is essentially
>> broken till we figure out the wrinkle. Adding a for speciesprofile loop at
>> the top was discussed as a solution of last resort.
>> > >
>> > > UniProtDatabaseProfile - while loop begins at line # 585
>> > >
>> > >
>> ---------------------------------------------------------------------------------------------------------------
>> > >
>> > > Also made modifications to getSystemsTableManager() which applies the
>> species customizations for each species profile selected. Seems correct to
>> me but please confirm.
>> > >
>> > >
>> --------------------------------------------------------------------------------------------------------------
>> > >
>> > > Discussions surrounding getPrimarySystemTableManager() assumed likely
>> bad coding since it seems to call for a customized schema although it is
>> identical to the default UniProt schema.
>> > >
>> > > It calls getPrimarySystemTableManagerCustomizations() which is
>> specific to Arabidopsis thaliana and Ecoli only.
>> > >
>> > > Didn't want to dig into this yet until other higher priority
>> modifications were done first plus I believe a discussion with Dr. D was
>> going to occur as well.
>> > >
>> > >
>> ---------------------------------------------------------------------------------------------------------------
>> > >
>> > > getRelationsTableManager() is the last method which remains untouched
>> but I will start reviewing and come up with a plan of attack.
>> > >
>> > >
>> --------------------------------------------------------------------------------------------------------------
>> > >
>> > > These are all the loose ends I can think of to document.
>> > >
>> > > Thanks!
>> > >
>> > > Richard
>> > >
>> > >
>> > >
>> > > On Wed, Aug 31, 2011 at 12:52 PM, Richard Brous <rbr...@gm...>
>> wrote:
>> > > Submitted changes to UniProtDatabaseProfile based on the logical
>> corrections from yesterdays convo with Dondi.
>> > >
>> > > These do not yet include the discussed optimizations, just wanted to
>> get it working and do some test exports... which completed successfully.
>> > >
>> > > I also added a for loop under the while loop in
>> getSystemTableManager() to ensure each query result is processed for each
>> selected species profile.
>> > > The loop is on line 587 and I added it because it seemed a solution to
>> have each species profile included... is this correct or should I be
>> submitting all at once versus each species?
>> > >
>> > > Richard
>> > >
>> > > <ATT00001..txt><ATT00002..txt>
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Special Offer -- Download ArcSight Logger for FREE!
>> > Finally, a world-class log management solution at an even better
>> > price-free! And you'll get a free "Love Thy Logs" t-shirt when you
>> > download Logger. Secure your free ArcSight Logger TODAY!
>> > http://p.sf.net/sfu/arcsisghtdev2dev
>> > _______________________________________________
>> > xmlpipedb-developer mailing list
>> > xml...@li...
>> > https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
>> >
>> > <ATT00001..txt><ATT00002..txt>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Special Offer -- Download ArcSight Logger for FREE!
>> Finally, a world-class log management solution at an even better
>> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
>> download Logger. Secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsisghtdev2dev
>> _______________________________________________
>> xmlpipedb-developer mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
>>
>
>

Thanks for sourcing this... I hadn't had any luck in doing so.
Compiled and running a test export now before I head to the beach.
Will let you know how it goes.
Richard
On Sun, Sep 4, 2011 at 12:25 AM, John David N. Dionisio <do...@lm...>wrote:
> Hi Rich,
>
> I took a look at the getInfoTableManager code and may have located the
> problem. I committed the possible fix, with a comment above it explaining
> why. Next time you do an export, keep an eye on that species name when more
> than one species is selected and report back as needed.
>
> John David N. Dionisio, PhD
> Associate Professor, Computer Science
> Associate Director, University Honors Program
> Loyola Marymount University
>
>
>
> On Sep 2, 2011, at 11:21 AM, Richard Brous wrote:
>
> > roger, thanks.
> >
> > richard
> >
> > On Fri, Sep 2, 2011 at 11:10 AM, John David N. Dionisio <do...@lm...>
> wrote:
> > OK, thanks. I will look into issue #1 concurrently and will report back.
> Regarding issue #2, I confirmed with Kam that we do need the per-species
> value for each ID. As we are prioritizing database approaches first, here
> you have a distinct exercise in SQL formation that is relevant to the
> tutorial course:
> >
> > - Modify the formed query so that it returns, for each ID, the
> corresponding species name. If successful, you will then have both ID and
> species name to provide to tableManager.submit, and you will not need an
> outer loop for every species profile.
> >
> > The way I suggest you do this is to form a valid query directly in
> PostgreSQL (i.e., via pgAdmin or psql). That should be pretty easy to get
> since you are logging the final query string --- just copy and paste that.
> Experiment with the query directly within PostgreSQL until you have one
> that works. Then transplant that into the code.
> >
> > John David N. Dionisio, PhD
> > Associate Professor, Computer Science
> > Associate Director, University Honors Program
> > Loyola Marymount University
> >
> >
> >
> > On Sep 2, 2011, at 11:04 AM, Richard Brous wrote:
> >
> > > OK, so still two outstanding issues regarding the last 2 modified
> methods:
> > >
> > > 1. getInfoTableManager()
> > >
> > > Still returning 3 species names when only two are selected. Returns one
> species name when only one is selected.
> > > - I will review the loop again and see if I can determine what is going
> on here.
> > >
> > > 2. getSystemTableManager()
> > >
> > > I added a for loop within the while condition which after discussions
> we know is incorrect. Will pull that out but we need to determine how to
> move forward with the issue of determining which species each id belongs to.
> removed loop and submitted to SourceForge but now build is essentially
> broken till we figure out the wrinkle. Adding a for speciesprofile loop at
> the top was discussed as a solution of last resort.
> > >
> > > UniProtDatabaseProfile - while loop begins at line # 585
> > >
> > >
> ---------------------------------------------------------------------------------------------------------------
> > >
> > > Also made modifications to getSystemsTableManager() which applies the
> species customizations for each species profile selected. Seems correct to
> me but please confirm.
> > >
> > >
> --------------------------------------------------------------------------------------------------------------
> > >
> > > Discussions surrounding getPrimarySystemTableManager() assumed likely
> bad coding since it seems to call for a customized schema although it is
> identical to the default UniProt schema.
> > >
> > > It calls getPrimarySystemTableManagerCustomizations() which is specific
> to Arabidopsis thaliana and Ecoli only.
> > >
> > > Didn't want to dig into this yet until other higher priority
> modifications were done first plus I believe a discussion with Dr. D was
> going to occur as well.
> > >
> > >
> ---------------------------------------------------------------------------------------------------------------
> > >
> > > getRelationsTableManager() is the last method which remains untouched
> but I will start reviewing and come up with a plan of attack.
> > >
> > >
> --------------------------------------------------------------------------------------------------------------
> > >
> > > These are all the loose ends I can think of to document.
> > >
> > > Thanks!
> > >
> > > Richard
> > >
> > >
> > >
> > > On Wed, Aug 31, 2011 at 12:52 PM, Richard Brous <rbr...@gm...>
> wrote:
> > > Submitted changes to UniProtDatabaseProfile based on the logical
> corrections from yesterdays convo with Dondi.
> > >
> > > These do not yet include the discussed optimizations, just wanted to
> get it working and do some test exports... which completed successfully.
> > >
> > > I also added a for loop under the while loop in getSystemTableManager()
> to ensure each query result is processed for each selected species profile.
> > > The loop is on line 587 and I added it because it seemed a solution to
> have each species profile included... is this correct or should I be
> submitting all at once versus each species?
> > >
> > > Richard
> > >
> > > <ATT00001..txt><ATT00002..txt>
> >
> >
> >
> ------------------------------------------------------------------------------
> > Special Offer -- Download ArcSight Logger for FREE!
> > Finally, a world-class log management solution at an even better
> > price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> > download Logger. Secure your free ArcSight Logger TODAY!
> > http://p.sf.net/sfu/arcsisghtdev2dev
> > _______________________________________________
> > xmlpipedb-developer mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
> >
> > <ATT00001..txt><ATT00002..txt>
>
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> xmlpipedb-developer mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
>

Hi Rich,
I took a look at the getInfoTableManager code and may have located the problem. I committed the possible fix, with a comment above it explaining why. Next time you do an export, keep an eye on that species name when more than one species is selected and report back as needed.
John David N. Dionisio, PhD
Associate Professor, Computer Science
Associate Director, University Honors Program
Loyola Marymount University
On Sep 2, 2011, at 11:21 AM, Richard Brous wrote:
> roger, thanks.
> 
> richard
> 
> On Fri, Sep 2, 2011 at 11:10 AM, John David N. Dionisio <do...@lm...> wrote:
> OK, thanks. I will look into issue #1 concurrently and will report back. Regarding issue #2, I confirmed with Kam that we do need the per-species value for each ID. As we are prioritizing database approaches first, here you have a distinct exercise in SQL formation that is relevant to the tutorial course:
> 
> - Modify the formed query so that it returns, for each ID, the corresponding species name. If successful, you will then have both ID and species name to provide to tableManager.submit, and you will not need an outer loop for every species profile.
> 
> The way I suggest you do this is to form a valid query directly in PostgreSQL (i.e., via pgAdmin or psql). That should be pretty easy to get since you are logging the final query string --- just copy and paste that. Experiment with the query directly within PostgreSQL until you have one that works. Then transplant that into the code.
> 
> John David N. Dionisio, PhD
> Associate Professor, Computer Science
> Associate Director, University Honors Program
> Loyola Marymount University
> 
> 
> 
> On Sep 2, 2011, at 11:04 AM, Richard Brous wrote:
> 
> > OK, so still two outstanding issues regarding the last 2 modified methods:
> >
> > 1. getInfoTableManager()
> >
> > Still returning 3 species names when only two are selected. Returns one species name when only one is selected.
> > - I will review the loop again and see if I can determine what is going on here.
> >
> > 2. getSystemTableManager()
> >
> > I added a for loop within the while condition which after discussions we know is incorrect. Will pull that out but we need to determine how to move forward with the issue of determining which species each id belongs to. removed loop and submitted to SourceForge but now build is essentially broken till we figure out the wrinkle. Adding a for speciesprofile loop at the top was discussed as a solution of last resort.
> >
> > UniProtDatabaseProfile - while loop begins at line # 585
> >
> > ---------------------------------------------------------------------------------------------------------------
> >
> > Also made modifications to getSystemsTableManager() which applies the species customizations for each species profile selected. Seems correct to me but please confirm.
> >
> > --------------------------------------------------------------------------------------------------------------
> >
> > Discussions surrounding getPrimarySystemTableManager() assumed likely bad coding since it seems to call for a customized schema although it is identical to the default UniProt schema.
> >
> > It calls getPrimarySystemTableManagerCustomizations() which is specific to Arabidopsis thaliana and Ecoli only.
> >
> > Didn't want to dig into this yet until other higher priority modifications were done first plus I believe a discussion with Dr. D was going to occur as well.
> >
> > ---------------------------------------------------------------------------------------------------------------
> >
> > getRelationsTableManager() is the last method which remains untouched but I will start reviewing and come up with a plan of attack.
> >
> > --------------------------------------------------------------------------------------------------------------
> >
> > These are all the loose ends I can think of to document.
> >
> > Thanks!
> >
> > Richard
> >
> >
> >
> > On Wed, Aug 31, 2011 at 12:52 PM, Richard Brous <rbr...@gm...> wrote:
> > Submitted changes to UniProtDatabaseProfile based on the logical corrections from yesterdays convo with Dondi.
> >
> > These do not yet include the discussed optimizations, just wanted to get it working and do some test exports... which completed successfully.
> >
> > I also added a for loop under the while loop in getSystemTableManager() to ensure each query result is processed for each selected species profile.
> > The loop is on line 587 and I added it because it seemed a solution to have each species profile included... is this correct or should I be submitting all at once versus each species?
> >
> > Richard
> >
> > <ATT00001..txt><ATT00002..txt>
> 
> 
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> xmlpipedb-developer mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
> 
> <ATT00001..txt><ATT00002..txt>

roger, thanks.
richard
On Fri, Sep 2, 2011 at 11:10 AM, John David N. Dionisio <do...@lm...>wrote:
> OK, thanks. I will look into issue #1 concurrently and will report back.
> Regarding issue #2, I confirmed with Kam that we do need the per-species
> value for each ID. As we are prioritizing database approaches first, here
> you have a distinct exercise in SQL formation that is relevant to the
> tutorial course:
>
> - Modify the formed query so that it returns, for each ID, the
> corresponding species name. If successful, you will then have both ID and
> species name to provide to tableManager.submit, and you will not need an
> outer loop for every species profile.
>
> The way I suggest you do this is to form a valid query directly in
> PostgreSQL (i.e., via pgAdmin or psql). That should be pretty easy to get
> since you are logging the final query string --- just copy and paste that.
> Experiment with the query directly within PostgreSQL until you have one
> that works. Then transplant that into the code.
>
> John David N. Dionisio, PhD
> Associate Professor, Computer Science
> Associate Director, University Honors Program
> Loyola Marymount University
>
>
>
> On Sep 2, 2011, at 11:04 AM, Richard Brous wrote:
>
> > OK, so still two outstanding issues regarding the last 2 modified
> methods:
> >
> > 1. getInfoTableManager()
> >
> > Still returning 3 species names when only two are selected. Returns one
> species name when only one is selected.
> > - I will review the loop again and see if I can determine what is going
> on here.
> >
> > 2. getSystemTableManager()
> >
> > I added a for loop within the while condition which after discussions we
> know is incorrect. Will pull that out but we need to determine how to move
> forward with the issue of determining which species each id belongs to.
> removed loop and submitted to SourceForge but now build is essentially
> broken till we figure out the wrinkle. Adding a for speciesprofile loop at
> the top was discussed as a solution of last resort.
> >
> > UniProtDatabaseProfile - while loop begins at line # 585
> >
> >
> ---------------------------------------------------------------------------------------------------------------
> >
> > Also made modifications to getSystemsTableManager() which applies the
> species customizations for each species profile selected. Seems correct to
> me but please confirm.
> >
> >
> --------------------------------------------------------------------------------------------------------------
> >
> > Discussions surrounding getPrimarySystemTableManager() assumed likely bad
> coding since it seems to call for a customized schema although it is
> identical to the default UniProt schema.
> >
> > It calls getPrimarySystemTableManagerCustomizations() which is specific
> to Arabidopsis thaliana and Ecoli only.
> >
> > Didn't want to dig into this yet until other higher priority
> modifications were done first plus I believe a discussion with Dr. D was
> going to occur as well.
> >
> >
> ---------------------------------------------------------------------------------------------------------------
> >
> > getRelationsTableManager() is the last method which remains untouched but
> I will start reviewing and come up with a plan of attack.
> >
> >
> --------------------------------------------------------------------------------------------------------------
> >
> > These are all the loose ends I can think of to document.
> >
> > Thanks!
> >
> > Richard
> >
> >
> >
> > On Wed, Aug 31, 2011 at 12:52 PM, Richard Brous <rbr...@gm...>
> wrote:
> > Submitted changes to UniProtDatabaseProfile based on the logical
> corrections from yesterdays convo with Dondi.
> >
> > These do not yet include the discussed optimizations, just wanted to get
> it working and do some test exports... which completed successfully.
> >
> > I also added a for loop under the while loop in getSystemTableManager()
> to ensure each query result is processed for each selected species profile.
> > The loop is on line 587 and I added it because it seemed a solution to
> have each species profile included... is this correct or should I be
> submitting all at once versus each species?
> >
> > Richard
> >
> > <ATT00001..txt><ATT00002..txt>
>
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> xmlpipedb-developer mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer
>

OK, thanks. I will look into issue #1 concurrently and will report back. Regarding issue #2, I confirmed with Kam that we do need the per-species value for each ID. As we are prioritizing database approaches first, here you have a distinct exercise in SQL formation that is relevant to the tutorial course:
- Modify the formed query so that it returns, for each ID, the corresponding species name. If successful, you will then have both ID and species name to provide to tableManager.submit, and you will not need an outer loop for every species profile.
The way I suggest you do this is to form a valid query directly in PostgreSQL (i.e., via pgAdmin or psql). That should be pretty easy to get since you are logging the final query string --- just copy and paste that. Experiment with the query directly within PostgreSQL until you have one that works. Then transplant that into the code.
John David N. Dionisio, PhD
Associate Professor, Computer Science
Associate Director, University Honors Program
Loyola Marymount University
On Sep 2, 2011, at 11:04 AM, Richard Brous wrote:
> OK, so still two outstanding issues regarding the last 2 modified methods:
> 
> 1. getInfoTableManager()
> 
> Still returning 3 species names when only two are selected. Returns one species name when only one is selected.
> - I will review the loop again and see if I can determine what is going on here.
> 
> 2. getSystemTableManager()
> 
> I added a for loop within the while condition which after discussions we know is incorrect. Will pull that out but we need to determine how to move forward with the issue of determining which species each id belongs to. removed loop and submitted to SourceForge but now build is essentially broken till we figure out the wrinkle. Adding a for speciesprofile loop at the top was discussed as a solution of last resort.
> 
> UniProtDatabaseProfile - while loop begins at line # 585
> 
> ---------------------------------------------------------------------------------------------------------------
> 
> Also made modifications to getSystemsTableManager() which applies the species customizations for each species profile selected. Seems correct to me but please confirm.
> 
> --------------------------------------------------------------------------------------------------------------
> 
> Discussions surrounding getPrimarySystemTableManager() assumed likely bad coding since it seems to call for a customized schema although it is identical to the default UniProt schema.
> 
> It calls getPrimarySystemTableManagerCustomizations() which is specific to Arabidopsis thaliana and Ecoli only.
> 
> Didn't want to dig into this yet until other higher priority modifications were done first plus I believe a discussion with Dr. D was going to occur as well. 
> 
> ---------------------------------------------------------------------------------------------------------------
> 
> getRelationsTableManager() is the last method which remains untouched but I will start reviewing and come up with a plan of attack.
> 
> --------------------------------------------------------------------------------------------------------------
> 
> These are all the loose ends I can think of to document.
> 
> Thanks!
> 
> Richard
> 
> 
> 
> On Wed, Aug 31, 2011 at 12:52 PM, Richard Brous <rbr...@gm...> wrote:
> Submitted changes to UniProtDatabaseProfile based on the logical corrections from yesterdays convo with Dondi.
> 
> These do not yet include the discussed optimizations, just wanted to get it working and do some test exports... which completed successfully.
> 
> I also added a for loop under the while loop in getSystemTableManager() to ensure each query result is processed for each selected species profile.
> The loop is on line 587 and I added it because it seemed a solution to have each species profile included... is this correct or should I be submitting all at once versus each species?
> 
> Richard
> 
> <ATT00001..txt><ATT00002..txt>

OK, so still two outstanding issues regarding the last 2 modified methods:
1. getInfoTableManager()
Still returning 3 species names when only two are selected. Returns one
species name when only one is selected.
- I will review the loop again and see if I can determine what is going on
here.
2. getSystemTableManager()
I added a for loop within the while condition which after discussions we
know is incorrect. Will pull that out but we need to determine how to move
forward with the issue of determining which species each id belongs to.
removed loop and submitted to SourceForge but now build is essentially
broken till we figure out the wrinkle. Adding a for speciesprofile loop at
the top was discussed as a solution of last resort.
UniProtDatabaseProfile - while loop begins at line # 585
---------------------------------------------------------------------------------------------------------------
Also made modifications to getSystemsTableManager() which applies the
species customizations for each species profile selected. Seems correct to
me but please confirm.
--------------------------------------------------------------------------------------------------------------
Discussions surrounding getPrimarySystemTableManager() assumed likely bad
coding since it seems to call for a customized schema although it is
identical to the default UniProt schema.
It calls getPrimarySystemTableManagerCustomizations() which is specific to
Arabidopsis thaliana and Ecoli only.
Didn't want to dig into this yet until other higher priority modifications
were done first plus I believe a discussion with Dr. D was going to occur as
well.
---------------------------------------------------------------------------------------------------------------
getRelationsTableManager() is the last method which remains untouched but I
will start reviewing and come up with a plan of attack.
--------------------------------------------------------------------------------------------------------------
These are all the loose ends I can think of to document.
Thanks!
Richard
On Wed, Aug 31, 2011 at 12:52 PM, Richard Brous <rbr...@gm...> wrote:
> Submitted changes to UniProtDatabaseProfile based on the logical
> corrections from yesterdays convo with Dondi.
>
> These do not yet include the discussed optimizations, just wanted to get it
> working and do some test exports... which completed successfully.
>
> I also added a for loop under the while loop in getSystemTableManager() to
> ensure each query result is processed for each selected species profile.
> The loop is on line 587 and I added it because it seemed a solution to have
> each species profile included... is this correct or should I be submitting
> all at once versus each species?
>
> Richard
>