genex-dev — GeneX developers

Re: [GeneX-dev] Schema changes

[<ja...@op...>]

Hey Todd,

Thanks for doing this, it was long overdue...

"Todd Peterson" <tf...@nc...> writes:

I wanted to discuss this first, because I think others will want to
comment. 

> 38. UserSequenceFeature table in ErWin has NOT NULL constraints on
>     nonunique_flag, con_fk and putative_csf attributes, DB does
>     not. CSF's are no longer supported, so the putative_csf
>     attribute is meaningless.
> Solution: Add NOT NULL constraint to nonunique_flag in DB. 

No. nonunique_flag was for CSF, and it is now gone. It needs to be
removed from ERWin.

> Remove NOT NULL constraint from con_fk in ErWin model. 

USF table now has both con_fk and provider_con_fk. This is slightly
confusing, but I believe there are two distint needs. Originally we
were using con_fk to indicate who supplied the nucleic acid material
that the USF was based on. We attempted to use owner_us_fk to indicate who
provided the information. The problem was that we overloaded the use
of UserSec here, because it should have only been used for
security/ownership of data in the DB.

When the DB is installed somewhere besides NCGR, the owner_us_fk needs
to point to a valid UserSec account for *that* installation, and since
I don't think every site wants to grant Wes Hatfield a login that can
change their UserSec entries, the owner_us_fk needs to point to the
local superuser account.

So we have:
con_fk: nucleic_acid supplier
provider_con_fk: who told us the sequence info

Perhaps these are too close to be useful as separate items and con_fk
should be removed.

Contact FKEYs
=============
This brings up the related issue:
All con_fk entries in the DB want to be renamed so that they are more
indicative of their intended role.

USF
ArrayMeasurement
ExperimentSet
---
provider_con_fk: the contact for the researcher that *originally*
supplied the information. This is different than the UserSec entry
that has permission to modify the information in the DB.

Spotter
Scanner
Software
ArrayLayout
---
con_fk => supplier_con_fk or provider_con_fk to indicate the
individual or organization that created the item.

Sample
--
con_fk => ??? We had a big discussion on how this could be used. I
believe it was intended to be the supplier of the original nucleic
acid material. I think that we discovered that there could be many
suppliers for a given sample (seed supplier, others?). Do we just want
to leave the name con_fk, and add some more types to ContactType
(seed_supplier, nucleic_acid_supplier, etc.)?

Protocol
--
has no con_fk, I believe it wants one. supplier_con_fk?
provider_con_fk?

> 1. In most tables, the actual database uses a size for varchar
>    fields of 128. The ErWin model has a wide variety of field sizes.
> Solution: Change ErWin model varchar fields to match database where
> the database field is 128 characters wide.  Reason: To make ErWin
> character fields a standard length where length is not an important
> consideration.

Yes, we agreed a while back that all varchars be 128, unless we needed
them to be smaller for some reason. One example is ExperimentSet:name
which inherits a Windows file name length limitation.

Todd, are there any others in the DB that are not 128?

> 4. ErWin model has AM_Group table, DB does not.
> Solution: Remove the table from ErWin.
> Reason: The table is obsolete.

yes.

> 2. AL_Spots table in ErWin has attributes of 
> 3. AM_Factorvalues table in ErWin has attributes of
> 5. AM_Spots table in ErWin has attributes of
> 6. AM_SuspectSpots table in ErWin has attributes of
> 7. ArrayMeasurement table in ErWin has attributes of
> 10. BlastHits table in ErWin has attributes
> 15. ExperimentFactors table in ErWin model has attributes
> 17. ExperimentSet table in ErWin model has attribute
> 23. HotSpots table in ErWin model has attributes
> 26. SampleProtocols table in ErWin has attribute
> 29. SpotLink table in ErWin model has attributes
> 32.TL_FactorValues table in ErWin model has attributes
> 35. Treatment_AMs table in ErWin has attributes
> 36. TreatmentLevel table in ErWin has attributes
> 39. USF_ExternalDBLink table in ErWin has attributes

These are all inherited fkeys. That ERWin created bogusly.

> 8. ArrayMeasurement table in DB has attributes of
>     hybridization_name varchar(128)
>     channel_name varchar(128)
> which are not in the ErWin model.  Solution: Add the attributes to
> the ErWin model.  Reason: These attributes exist in the Curation
> Tool, DB and in GeneXML so they belong in ErWin as well.

yes. Also ArrayMeasurement table now has:

provider_con_fk int4 (references Contact con_pk)

> 9. ArrayMeasurement table in ErWin has NOT NULL constraint for
> 16. ExperimentSet table in ErWin model has NOT NULL constraint for
> 18. ExperimentSet table in ErWin model has NOT NULL constraint on

yes.

> 11. CanonicalSequenceFeature table exists in ErWin model but does
> 13. CSF_ExternalDBLinktable exists in ErWin model but does not exist in DB.
> 24. RelatedCSF table exists in ErWin, does not exist in DB.
> 37. UserCanonicalLink table exists in ErWin but does not exist in DB.

These tables were removed because CSF is no longer supported

> 12. CitationLink table in ErWin model has attributes

This table was removed and should be removed from ERWin.

> 14. ExperimentFactors table in ErWin has attribute of
>     measurement_units, DB calls this attribute factor_units.
> Solution: Change the measurement_units attribute in ErWin to be factor_units.
> Reason: ErWin attribute name does not match DB attribute name.

yes

> 19. ExperimentSet table in DB has cit_fk attribute, ErWin does not.
> Solution: add cit_fk attribute to ErWin model.
> Reason: attribute required.

> 20. ExternalDatabase table in DB has attribute of main_url, ErWin
> 21. ExternalDatabase table in DB has attribute of parameterized_url

Correct these were changed to generalize the table to allow both types
of URL.

> 22. ExternalDatabase table in DB has NOT NULL constraint on name
>     attribute, ErWin does not.
> Solution: add constraint to ErWin model.
> Reason: name is required.

name is the pkey for the table

> 25. Sample table in ErWin and DB do not have a name
>     attribute. Currently, the Curation Tool is using the cell_line
>     attribute to hold this information. This was a hack to avoid
>     changing DB, GeneXML, and translators.
> Solution: Add attribute to ErWin model, DB, GeneXML, XML2DB, DB2XML
> and any other affected tools and models.  Reason: Sample needs a
> unique identifier field.

OK. Thanks for catching that.

> 27. Scanner table in ErWin has attribute model_num, DB has attribute
>     model_description.
> Solution: change name in ErWin.
> Reason: to make DB and ErWin consistent.

yes.

> 28. Species table in DB and ErWin have attribute of num_chromosomes
>     which has type of char. This attribute should be int or varchar.
> Solution: change the type to int in DB, ErWin, and other affected
> tools and models.  Reason: char is not sufficient to represent this
> attribute.

I believe the type was originally intened to be 'byte' since no
organisms I know that are being studied have more than 255
chromosomes, but you're correct we should change it to int.

> 30. Spotter table in ErWin has attribute model_num, DB has attribute
>     model_description.
> Solution: change name in ErWin.
> Reason: to make DB and ErWin consistent.

yes.

> 31. Spotter table in ErWin has attribute of con_pk with a NOT NULL
>     constraint, DB defines this constraint as con_fk with no NOT
>     NULL constraint.
> Solution: rename constraint in ErWin and remove NOT NULL constraint.
> Reason: name is wrong and constraint is unecessary.

yes.

> 33. TL_FactorValues table in DB has attribute reference_value
>     varchar(128) NOT NULL which does not exist in ErWin model.
> Solution: add attribute to ErWin model.
> Reason: attribute required for TBD.

yes.

> 34. Treatment_AMs table in ErWin has attributes of am_pk and tl_pk,
>     DB calls these attributes am_fk and tl_fk, respectively.
> Solution: change attribute names in ErWin.
> Reason: names are incorrect.

yes.

jas.

Re: [GeneX-dev] Schema changes

[Todd P. <tf...@nc...>]

Found a way to trick Erwin into not adding these attributes.

----- Original Message ----- 
From: "Jason E. Stewart" <ja...@op...>
To: <gen...@li...>
Sent: Wednesday, January 31, 2001 1:58 PM
Subject: Re: [GeneX-dev] Schema changes


> "Todd Peterson" <tf...@nc...> writes:
> 
> > 2. AL_Spots table in ErWin has attributes of 
> >     al_con_fk
> >     usf_spc_fk
> >     usf_owner_us_fk
> >     usf_con_fk
> > which do not exist in the DB.
> > Solution: Remove the attributes from the ErWin model.
> > Reason: The attributes are obsolete.
> 
> Actually, this is just one of those ERWin *features*. The al_* are
> 'inherited' from the ArrayLayout table, and the usf_* are 'inherited'
> from the USF table.
> 
> This issue has come up again and again with bogus fkeys being
> inherited across tables.
> 
> FYI.
> jas.
> 
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev
> 

Re: [GeneX-dev] Schema changes

[Michael P. <mic...@ho...>]

Todd,

 It doesn't appear in your list, but the primary key am_pk in
arraymeasurement doesn't have a unique index associated with it,
so there is no constraint of uniqueness. There may be some other tables for
which this is the case. This is probably assumed in ERWin for
anything classified as a primary key, and not intended in the acutal
postgresql schema


Regards,

Michael Pear

Re: [GeneX-dev] Controlled Vocabs in DB

[<ja...@op...>]

"Greg D. Colello" <gd...@nc...> writes:

> I'm sure Jason would applaud this idea. He has been saying the same thing since 
> 6 months ago.
> 
> >Having a separate table for each control vocabulary is extremely
> >tedious. I
> propose the following table structure:
> >
> >table: 
> >    ControlVocabulary
> >attributes:
> >    vocabulary_name varchar(80) NOT NULL
> >    term_string varchar(48) NOT NULL
> >    description text

<applaud sound_volume="loud"/>

I would suggest we be liberal and make them varchar(128). I think we
agreed all varchars be 128 unless we have a reason to want them
short. 

jas.

Re: [GeneX-dev] Bug tracking on sourceforge

[<ja...@op...>]

"Greg D. Colello" <gd...@nc...> writes:

> I really appreciate you taking care of this, but I don't understand
> your bug priority assignments.

You're welcome. I figure this is a critical enough issue that we want
to make sure that it's well understood and working within our
relatively small group before we start getting other developers
involved. 

> The way I think about GeneX releases is that we will have a CURRENT
> production release, which should be stable unless emergency patches
> are required. Patches are the only acceptable repair mechanism to a
> CURRENT release. Therefore, patches should have a priority named
> after them. Otherwise another production release must be built, but
> then that's the NEXT release.
> 
> At the same time that we have have a CURRENT release in deployment,
> we are developing the NEXT release. It will have its own priorities.
> 
> Then there are simply FUTURE release items.

Ok. Terminology her is critical. 

First, remember that we will soon have a PRODUCTION and a DEVELOPMENT
branch (or at least I hope this is decided and that I'm not telling
everybody else it needs to be this way). Let's deal with each
separately to see if they differ somehow.

<terminology>
PRODUCTION is the stable release. We should not be adding new features
here. Only bug-fixes and items that get back-ported from DEVELOPMENT
because they are critical.

DEVELOPMENT is the exploration branch. New features are added here
until they become stable, at which time the stable version of
DEVELOPMENT becomes the new release of PRODUCTION (with an
accompanying version number increase).

For example, soon we will release v1.0.0 of the Server. all 1.0.x
releases after that will be bug fixes on the stable 1.0 PRODUCTION
release. The 1.1.x branch is DEVELOPMENT, and when 1.1 becomes stable,
we release 1.2.0 which is the new PRODUCTION and 1.3.0 becomes the new
DEVELOPMENT.

Let's define CURRENT to mean the thing we just released. We'll define
NEXT as the thing we're currently working gathering pathces for. If
we had a FUTURE category it would mean items not intended to go into
NEXT. 
</terminology>

Now lets look at were the bugs fall.

We can never effect CURRENT, it's already out the door, so all bugs go
in either NEXT or FUTURE, don't they? PRODUCTION does not have a
concept of FUTURE, either it's an important piece and it goes in NEXT
or it isn't important and it shouldn't be in PRODUCTION, it should be
in DEVELOPMENT, right? And for DEVELOPMENT all bugs that are important
go in NEXT, and those that can wait go in FUTURE.

That leaves three categories:
PRODUCTION:NEXT
DEVELOPMENT:NEXT
DEVELOPMENT:FUTURE

According to the system I proposed:

>SourceForge Bug track priority
>9: Critical Failure, Must Fix Immediately               
>8: Major Bug Must fix in this release 
>7: Important BugFix in this release if possible  
>6: Minor Bug, re-examine priority in next release
>5-1: Don't work on unless instructed

<9> stays the same, it is for items that are time sensitive, this could
be fixing a piece of hardware, to restarting a wWW server. These are
drop-whatever- you're-doing items. If they apply at all to software,
then they are likely to be PRODUCTION related, requiring an immediate
bug-fix release

<8> Applies equally to PRODUCTION and DEVELOPMENT
<7> seems only to apply to DEVELOPMENT, if it isn't really so
important that it needs fixing for the next release, it sounds like a
DEVELOPEMENT issue
<6> is FUTURE, and only applies to DEVELOPMENT
<5-1> are stuff that we're just keeping on the back burning for
another time.

Comments? Am I halucinatory?

jas.

Re: [GeneX-dev] Controlled Vocabs in DB

[Greg D. C. <gd...@nc...>]

I'm sure Jason would applaud this idea. He has been saying the same thing since 
6 months ago.

Greg

>From: "Todd Peterson" <tf...@nc...>
>To: <gen...@li...>
>MIME-Version: 1.0
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
>Subject: [GeneX-dev] Controlled Vocabs in DB
>Date: Wed, 31 Jan 2001 16:06:35 -0700
>
>Having a separate table for each control vocabulary is extremely tedious. I 
propose the following table structure:
>
>table: 
>    ControlVocabulary
>attributes:
>    vocabulary_name varchar(80) NOT NULL
>    term_string varchar(48) NOT NULL
>    description text
>
>Advantages: less tables which all have the same structure. less maintenance. 
generic. code simplification.
>Disadvantages: code changes in DB2XML, XML2DB, control bundle generator. 
GeneXML should NOT change.
>
>I realize this is probably something for redesign but wanted to get thoughts 
churning.

Re: [GeneX-dev] Bug tracking on sourceforge

[Greg D. C. <gd...@nc...>]

Jason:

I really appreciate you taking care of this, but I don't understand your bug 
priority assignments.

The way I think about GeneX releases is that we will have a CURRENT production 
release, which should be stable unless emergency patches are required. Patches 
are the only acceptable repair mechanism to a CURRENT release. Therefore, 
patches should have a priority named after them. Otherwise another production 
release must be built, but then that's the NEXT release.

At the same time that we have have a CURRENT release in deployment, we are 
developing the NEXT release. It will have its own priorities.

Then there are simply FUTURE release items.

Therefore, it seems like we need bug priorities that reflect these divisions.

Your priorities seem to all be about the CURRENT and FUTURE releases. Or is it 
about the NEXT and FUTURE releases? Maybe there is some kind of symantic problem 
with my understanding of the meanings of CURRENT and NEXT?

Greg

>Delivered-To: fix...@li...@fixme
>To: gen...@li...
>Cc: gen...@li...
>Subject: Re: [GeneX-dev] Bug tracking on sourceforge
>Mime-Version: 1.0 (generated by tm-edit 1.5)
>From: ja...@op... (Jason E. Stewart)
>Date: 31 Jan 2001 13:13:21 -0700
>
>Here then is the proposal for the use of the SF bug tracking system.
>
>SourceForge Bug track priority
>9: Critical Failure, Must Fix Immediately               
>8: Major Bug Must fix in this release 
>7: Important BugFix in this release if possible  
>6: Minor Bug, re-examine priority in next release
>5-1: Don't work on unless instructed
>
>The procedure:
>When a bug is submitted agains you
>* If you *don't* think it belongs to you, re-assign it to someone who
>   can decide.
>* If it does apply:
>1) If the priority is not set correctly, correct it in the bug admin
>   page (https://sourceforge.net/bugs/?group_id=16453)
>2) Forward it to the buglist (gen...@li...), and
>   Make a note in the forward to any other developers ought to pay
>   attention. 
>
>jas.
>
>_______________________________________________
>Genex-dev mailing list
>Gen...@li...
>http://lists.sourceforge.net/lists/listinfo/genex-dev

Re: [GeneX-dev] Schema changes

[Greg D. C. <gd...@nc...>]

Todd:

Wow!! Nice job. We have needed someone to do this for a long time.

Greg

>From: "Todd Peterson" <tf...@nc...>
>To: <gen...@li...>
>MIME-Version: 1.0
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
>Subject: [GeneX-dev] Schema changes
>Date: Wed, 31 Jan 2001 13:10:21 -0700
>
>Here is the list of differences between the current database on the genex 
machine and the model in ErWin. The proposed modification and reason for change 
is noted. Please comment if you have concerns. I believe there is enough 
material here to warrant a peer review on the proposed solutions. Please note 
that nearly every genex component is affected by some of the solutions. I will 
not change anything anywhere until we have agreement.
>
>1. In most tables, the actual database uses a size for varchar fields of 128. 
The ErWin model has a wide variety of field sizes.
>Solution: Change ErWin model varchar fields to match database where the 
database field is 128 characters wide.
>Reason: To make ErWin character fields a standard length where length is not an 
important consideration.
>
>2. AL_Spots table in ErWin has attributes of 
>    al_con_fk
>    usf_spc_fk
>    usf_owner_us_fk
>    usf_con_fk
>which do not exist in the DB.
>Solution: Remove the attributes from the ErWin model.
>Reason: The attributes are obsolete.
>
>3. AM_Factorvalues table in ErWin has attributes of
>    ef_es_fk
>    ef_es_us_con_fk
>    ef_es_us_fk
>    am_us_fk
>    am_us_con_fk
>    am_primary_es_fk
>which do not exist in the DB.
>Solution: Remove the attributes from the ErWin model.
>Reason: The attributes are obsolete.
>
>4. ErWin model has AM_Group table, DB does not.
>Solution: Remove the table from ErWin.
>Reason: The table is obsolete.
>
>5. AM_Spots table in ErWin has attributes of
>    usf_owner_us_Fk
>    am_primary_es_fk
>    am_us_con_fk
>    usf_con_fk
>    am_us_fk
>    usf_spc_fk
>which do not exist in the DB.
>Solution: Remove the attributes from the ErWin model.
>Reason: The attributes are obsolete.
>
>6. AM_SuspectSpots table in ErWin has attributes of
>    ams_am_primary_es_fk
>    am_us_fk
>    ams_am_fk
>    am_us_con_fk
>    ams_am_us_fk
>    am_primary_es_fk
>    ams_am_us_con_fk
>which do not exist in the DB.
>Solution: Remove the attributes from the ErWin model.
>Reason: The attributes are obsolete.
>
>7. ArrayMeasurement table in ErWin has attributes of
>    us_con_fk
>    amg_fk
>    con_fk
>    smp_spc_fk
>which do not exist in the DB.
>Solution: Remove the attributes from the ErWin model.
>Reason: The attributes are obsolete.
>
>8. ArrayMeasurement table in DB has attributes of
>    hybridization_name varchar(128)
>    channel_name varchar(128)
>which are not in the ErWin model.
>Solution: Add the attributes to the ErWin model.
>Reason: These attributes exist in the Curation Tool, DB and in GeneXML so they 
belong in ErWin as well.
>
>9. ArrayMeasurement table in ErWin has NOT NULL constraint for sptr_fk, DB does 
not.
>Solution: Remove constraint from ErWin model.
>Reason: Constraint is unecessary.
>
>10. BlastHits table in ErWin has attributes
>    usf_spc_fk
>    owner_us_fk
>    usf_con_fk
>which do not exist in the DB. 
>Solution: Remove the attributes from the ErWin model.
>Reason: The attributes are obsolete.
>
>11. CanonicalSequenceFeature table exists in ErWin model but does not exist in 
DB.
>Solution: Remove the table from the ErWin model.
>Reason: CSF's are no longer supported.
>
>12. CitationLink table in ErWin model has attributes
>    es_us_fk
>    es_us_con_fk
>which do not exist in the DB. 
>Solution: Remove the attributes from the ErWin model.
>Reason: The attributes are obsolete.
>
>13. CSF_ExternalDBLinktable exists in ErWin model but does not exist in DB.
>Solution: Remove the table from the ErWin model.
>Reason: CSF's are no longer supported.
>
>14. ExperimentFactors table in ErWin has attribute of measurement_units, DB 
calls this attribute factor_units.
>Solution: Change the measurement_units attribute in ErWin to be factor_units.
>Reason: ErWin attribute name does not match DB attribute name.
>
>15. ExperimentFactors table in ErWin model has attributes
>    es_us_fk
>    es_us_con_fk
>which do not exist in the DB. 
>Solution: Remove the attributes from the ErWin model.
>Reason: The attributes are obsolete.
>
>16. ExperimentSet table in ErWin model has NOT NULL constraint for 
archive_bundle_ref, DB does not.
>Solution: Remove NOT NULL constraint from archive_bundle_ref in ErWin model.
>Reason: Constraint is unecessary.
>
>17. ExperimentSet table in ErWin model has attribute
>    us_con_fk
>which do not exist in the DB. 
>Solution: Remove the attributes from the ErWin model.
>Reason: The attributes are obsolete.
>
>18. ExperimentSet table in ErWin model has NOT NULL constraint on 
analysis_description attribute, DB does not.
>Solution: remove NOT NULL constraint in ErWin model.
>Reason: constraint is unecessary
>
>19. ExperimentSet table in DB has cit_fk attribute, ErWin does not.
>Solution: add cit_fk attribute to ErWin model.
>Reason: attribute required.
>
>20. ExternalDatabase table in DB has attribute of main_url, ErWin model has 
attribute of url.
>Solution: change name in ErWin.
>Reason: to make name consistent with DB.
>
>21. ExternalDatabase table in DB has attribute of parameterized_url 
varchar(128), ErWin model has attribute of is_parameterized bit.
>Solution: change name and type in ErWin.
>Reason: to make name and type consistent with DB.
>
>22. ExternalDatabase table in DB has NOT NULL constraint on name attribute, 
ErWin does not.
>Solution: add constraint to ErWin model.
>Reason: name is required.
>
>23. HotSpots table in ErWin model has attributes
>    usf_spc_Fk
>    usf_con_fk
>    es_us_con_fk
>    es_us_fk
>    usf_owner_us_fk
>which do not exist in the DB. 
>Solution: Remove the attributes from the ErWin model.
>Reason: The attributes are obsolete.
>
>24. RelatedCSF table exists in ErWin, does not exist in DB.
>Solution: remove RelatedCSF table from ErWin.
>Reason: CSF's are no longer supported.
>
>25. Sample table in ErWin and DB do not have a name attribute. Currently, the 
Curation Tool is using the cell_line attribute to hold this information. This 
was a hack to avoid changing DB, GeneXML, and translators.
>Solution: Add attribute to ErWin model, DB, GeneXML, XML2DB, DB2XML and any 
other affected tools and models.
>Reason: Sample needs a unique identifier field.
>
>26. SampleProtocols table in ErWin has attribute
>    smp_spc_fk
>which does not exist in the DB. 
>Solution: Remove the attribute from the ErWin model.
>Reason: The attribute is obsolete.
>
>27. Scanner table in ErWin has attribute model_num, DB has attribute 
model_description.
>Solution: change name in ErWin.
>Reason: to make DB and ErWin consistent.
>
>28. Species table in DB and ErWin have attribute of num_chromosomes which has 
type of char. This attribute should be int or varchar.
>Solution: change the type to int in DB, ErWin, and other affected tools and 
models.
>Reason: char is not sufficient to represent this attribute.
>
>29. SpotLink table in ErWin model has attributes
>    ams_am_us_fk
>    als_al_con_fk
>    ams_am_us_con_fk
>    ams_am_primary_es_fk
>    als_al_fk
>    ams_am_fk
>which do not exist in the DB. 
>Solution: Remove the attributes from the ErWin model.
>Reason: The attributes are obsolete.
>
>30. Spotter table in ErWin has attribute model_num, DB has attribute 
model_description.
>Solution: change name in ErWin.
>Reason: to make DB and ErWin consistent.
>
>31. Spotter table in ErWin has attribute of con_pk with a NOT NULL constraint, 
DB defines this constraint as con_fk with no NOT NULL constraint.
>Solution: rename constraint in ErWin and remove NOT NULL constraint.
>Reason: name is wrong and constraint is unecessary.
>
>32.TL_FactorValues table in ErWin model has attributes
>    ratio_am_fk
>    ef_es_us_con_fk
>    es_us_fk
>    es_us_con_fk
>    es_fk
>    ef_es_fk
>    ef_es_us_fk
>which do not exist in the DB. 
>Solution: Remove the attributes from the ErWin model.
>Reason: The attributes are obsolete.
>
>33. TL_FactorValues table in DB has attribute reference_value varchar(128) NOT 
NULL which does not exist in ErWin model.
>Solution: add attribute to ErWin model.
>Reason: attribute required for TBD.
>
>34. Treatment_AMs table in ErWin has attributes of am_pk and tl_pk, DB calls 
these attributes am_fk and tl_fk, respectively.
>Solution: change attribute names in ErWin.
>Reason: names are incorrect.
>
>35. Treatment_AMs table in ErWin has attributes
>    primary_es_fk
>    us_con_fk
>    us_fk
>    tl_es_fk
>    tl_es_us_fk
>    tl_ration_am_fk
>    tl_us_con_fk
>which do not exist in the DB. 
>Solution: Remove the attributes from the ErWin model.
>Reason: The attributes are obsolete.
>
>36. TreatmentLevel table in ErWin has attributes
>    am_con_fk
>    es_us_fk
>    am_us_fk
>    es_us_con_fk
>    am_primary_es_fk
>which do not exist in the DB. 
>Solution: Remove the attributes from the ErWin model.
>Reason: The attributes are obsolete.
>
>37. UserCanonicalLink table exists in ErWin but does not exist in DB.
>Solution: remove table from ErWin.
>Reason: CSF's are no longer supported.
>
>38. UserSequenceFeature table in ErWin has NOT NULL constraints on 
nonunique_flag, con_fk and putative_csf attributes, DB does not. CSF's are no 
longer supported, so the putative_csf attribute is meaningless.
>Solution: Add NOT NULL constraint to nonunique_flag in DB. Remove NOT NULL 
constraint from con_fk in ErWin model. Remove putative_csf attribute from DB, 
ErWin and all other affected tools and models.
>Reason: A bit attribute (nonunique_flag) must either be true or false. The NOT 
NULL constraint on con_fk is unecessary. The putative_csf attribute is no longer 
supported since CSF's are no longer supported.
>
>39. USF_ExternalDBLink table in ErWin has attributes
>    usf_con_fk
>    usf_spc_fk
>    usf_owner_us_fk
>which do not exist in the DB. 
>Solution: Remove the attributes from the ErWin model.
>Reason: The attributes are obsolete.
>

Sorry, Sorry --Re: [GeneX-dev] Possible CurationTool V0.81 Bug for data import

[Jiaye Z. <ze...@in...>]

Sorry, Sorry, Sorry!!!
My bad, somehow I managed to miss the big yellow "finish" button. heehee.
Please don't shoot me. What happend was that after validating the files again 
the col files, I never clicked the finish button (thought it was just a status 
window for over 10 time!) and clicked on close button. Of course, without 
knowing that the next screen should look like, I thought everything imported 
just fine. After talking to greg, I realized the crime that I had committed. So 
please forgive me...I would bring up one point though, perhaps it is helpful to 
have the "finish" button say "click here to finish" instead to help dummies like 
me?

jiaye


Quoting Jiaye Zhou <ze...@in...>:

> Hi Lonny, Greg,
> 
>   I am helping Wei Chen from UNM High Performance Computing Center
> preparing a 
> data set for upload using the Curation Tool. She downloaded the latest
> version 
> (v0.81). Seems there is a bug, unless I'm terribly mistaken. After
> selecting 
> "creating new experiment set" and in the "Import Experiement Set Data
> File" 
> section, "New Experiment Set" window. I was able to import a set of
> files 
> (sequence feature, arraylayout and measurement data file). But only
> sequence 
> feature file has the "Import Genex Data" button activated. No matter
> what I do, 
> the button is grayed out when I selet the other files. After messing
> with it for 
> a while, I decided to use the test data files included with the
> distribution, 
> turned out that the same thing happened. Curation Tool is allowing only 
> importing data from the sequence feature file and not the others. Is
> this 
> another "random bug" that got introduced with the new version? Jason
> couldn't 
> get v0.81 to run on his machine, so I could not verify this. Could
> someone else, 
> perhaps someone knows the CT better than I, test it? We are running it
> on NT.
> Thanks,
> 
> Jiaye 
> 
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev
> 

[GeneX-dev] Possible CurationTool V0.81 Bug for data import

[Jiaye Z. <ze...@in...>]

Hi Lonny, Greg,

  I am helping Wei Chen from UNM High Performance Computing Center preparing a 
data set for upload using the Curation Tool. She downloaded the latest version 
(v0.81). Seems there is a bug, unless I'm terribly mistaken. After selecting 
"creating new experiment set" and in the "Import Experiement Set Data File" 
section, "New Experiment Set" window. I was able to import a set of files 
(sequence feature, arraylayout and measurement data file). But only sequence 
feature file has the "Import Genex Data" button activated. No matter what I do, 
the button is grayed out when I selet the other files. After messing with it for 
a while, I decided to use the test data files included with the distribution, 
turned out that the same thing happened. Curation Tool is allowing only 
importing data from the sequence feature file and not the others. Is this 
another "random bug" that got introduced with the new version? Jason couldn't 
get v0.81 to run on his machine, so I could not verify this. Could someone else, 
perhaps someone knows the CT better than I, test it? We are running it on NT.
Thanks,

Jiaye 

[GeneX-dev] reaper function, cron entry added to install-all

[Harry M. <man...@ho...>]

Test it out.  genex_reaper.pl has been added to the CyberT-dist dir as a .in
Useful in general to watch for directory bloat.
-- 
Cheers,
Harry

Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || man...@ho...

[GeneX-dev] Controlled Vocabs in DB

[Todd P. <tf...@nc...>]

Having a separate table for each control vocabulary is extremely =
tedious. I propose the following table structure:

table:=20
    ControlVocabulary
attributes:
    vocabulary_name varchar(80) NOT NULL
    term_string varchar(48) NOT NULL
    description text

Advantages: less tables which all have the same structure. less =
maintenance. generic. code simplification.
Disadvantages: code changes in DB2XML, XML2DB, control bundle generator. =
GeneXML should NOT change.

I realize this is probably something for redesign but wanted to get =
thoughts churning.

Re: [GeneX-dev] email addresses in the installation script

[<ja...@op...>]

Hey Harry,

We should not escape the email addresses.

Perl only upchucks if you place them inside an interpolated string
(i.e. a string with double-quotes). If you place them inside a
non-interpolated string (i.e. a string with single-quotes) all is
well. 

Example:

my $email_address = 'ja...@op...';

print STDOUT <<"EOF";

Hi,

You told me to send email to $email_address

EOF

However, if you write

my $email_address = "ja...@op...";

Perl will barf immediately.

jas.

"Harry Mangalam" <man...@ho...> writes:

> Did we make a decision about how to represent email addresses in the
> install-all.pl script?  If we don't convert them to yadda\@address
> in scripts, perl upchucks. On the other hand if we do convert them
> bulk to \@, it'll look funny in regular text messages.

[GeneX-dev] email addresses in the installation script

[Harry M. <man...@ho...>]

Hi All,

Did we make a decision about how to represent email addresses in the install-all.pl script?  If we don't convert them to yadda\@address in scripts, perl upchucks. On the other hand if we do convert
them bulk to \@, it'll look funny in regular text messages.

Is there a sophisticated way to do this or do we just convert on the cfly as we need them?
-- 
Cheers,
Harry

Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || man...@ho...

Re: [GeneX-dev] Schema changes

[<ja...@op...>]

"Todd Peterson" <tf...@nc...> writes:

> 2. AL_Spots table in ErWin has attributes of 
>     al_con_fk
>     usf_spc_fk
>     usf_owner_us_fk
>     usf_con_fk
> which do not exist in the DB.
> Solution: Remove the attributes from the ErWin model.
> Reason: The attributes are obsolete.

Actually, this is just one of those ERWin *features*. The al_* are
'inherited' from the ArrayLayout table, and the usf_* are 'inherited'
from the USF table.

This issue has come up again and again with bogus fkeys being
inherited across tables.

FYI.
jas.

Re: [GeneX-dev] Bug tracking on sourceforge

[<ja...@op...>]

Here then is the proposal for the use of the SF bug tracking system.

SourceForge Bug track priority
9: Critical Failure, Must Fix Immediately               
8: Major Bug Must fix in this release 
7: Important BugFix in this release if possible  
6: Minor Bug, re-examine priority in next release
5-1: Don't work on unless instructed

The procedure:
When a bug is submitted agains you
* If you *don't* think it belongs to you, re-assign it to someone who
   can decide.
* If it does apply:
1) If the priority is not set correctly, correct it in the bug admin
   page (https://sourceforge.net/bugs/?group_id=16453)
2) Forward it to the buglist (gen...@li...), and
   Make a note in the forward to any other developers ought to pay
   attention. 

jas.

Re: [GeneX-dev] Bug tracking on sourceforge

[Lonnie M. <lx...@nc...>]

I agree with Harry, letsleave it like it is in sourceforge.

Lonny


> 
> "Jason E. Stewart" wrote:
> > What do people feel. I think that 9 priorities are pointless, there
> > are at least 3 that will never get used.
> 
> 9 categories are useless.  Probably 6 are too many; 4 is about right, but I don't really care too much; I'll ignore all less than the top 2 :).
> 
> Re: the priority numbering inversion.  Not enough confusion to worry about.  We're big boys. We can count up as well as down.  In conversation, refer to HIGH priority vs low pri and the point will be
> made.
> 
> 
> 
> > Todd, if you're suggesting that we switch the SF priority scheme so
> > that 1 is high and 9 is low, that might be a problem. Since that
> > information is auto-generated by the SF scripts, we cannot change
> > it. That means users that examine our bug list will see all theses
> > priority one bugs, which sourceforge claims is *low* priority.
> > 
> > Perhaps what we want is to map:
> > 
> > Genex                                  SourceForge
> > Bugzilla:                              Bug track
> > 
> > P0: Critical Failure                   9:
> >     Must Fix Immediately
> > P1  Major Bug                          8:
> >     Must fix in this release
> > P2  Important Bug                      7:
> >     Fix in this release if possible
> > P3  Minor Bug                          6:
> >     Fix in next release
> > P4  Minor Bug                          --
> >     (redundant with P3)
> > P5  Don't work on unless instructed    5: (or 1:)?
> > 
> > jas.
> > 
> > _______________________________________________
> > Genex-dev mailing list
> > Gen...@li...
> > http://lists.sourceforge.net/lists/listinfo/genex-dev
> 
> -- 
> Cheers,
> Harry
> 
> Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || man...@ho...
> 
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev
> 

[GeneX-dev] Schema changes

[Todd P. <tf...@nc...>]

Here is the list of differences between the current database on the =
genex machine and the model in ErWin. The proposed modification and =
reason for change is noted. Please comment if you have concerns. I =
believe there is enough material here to warrant a peer review on the =
proposed solutions. Please note that nearly every genex component is =
affected by some of the solutions. I will not change anything anywhere =
until we have agreement.

1. In most tables, the actual database uses a size for varchar fields of =
128. The ErWin model has a wide variety of field sizes.
Solution: Change ErWin model varchar fields to match database where the =
database field is 128 characters wide.
Reason: To make ErWin character fields a standard length where length is =
not an important consideration.

2. AL_Spots table in ErWin has attributes of=20
    al_con_fk
    usf_spc_fk
    usf_owner_us_fk
    usf_con_fk
which do not exist in the DB.
Solution: Remove the attributes from the ErWin model.
Reason: The attributes are obsolete.

3. AM_Factorvalues table in ErWin has attributes of
    ef_es_fk
    ef_es_us_con_fk
    ef_es_us_fk
    am_us_fk
    am_us_con_fk
    am_primary_es_fk
which do not exist in the DB.
Solution: Remove the attributes from the ErWin model.
Reason: The attributes are obsolete.

4. ErWin model has AM_Group table, DB does not.
Solution: Remove the table from ErWin.
Reason: The table is obsolete.

5. AM_Spots table in ErWin has attributes of
    usf_owner_us_Fk
    am_primary_es_fk
    am_us_con_fk
    usf_con_fk
    am_us_fk
    usf_spc_fk
which do not exist in the DB.
Solution: Remove the attributes from the ErWin model.
Reason: The attributes are obsolete.

6. AM_SuspectSpots table in ErWin has attributes of
    ams_am_primary_es_fk
    am_us_fk
    ams_am_fk
    am_us_con_fk
    ams_am_us_fk
    am_primary_es_fk
    ams_am_us_con_fk
which do not exist in the DB.
Solution: Remove the attributes from the ErWin model.
Reason: The attributes are obsolete.

7. ArrayMeasurement table in ErWin has attributes of
    us_con_fk
    amg_fk
    con_fk
    smp_spc_fk
which do not exist in the DB.
Solution: Remove the attributes from the ErWin model.
Reason: The attributes are obsolete.

8. ArrayMeasurement table in DB has attributes of
    hybridization_name varchar(128)
    channel_name varchar(128)
which are not in the ErWin model.
Solution: Add the attributes to the ErWin model.
Reason: These attributes exist in the Curation Tool, DB and in GeneXML =
so they belong in ErWin as well.

9. ArrayMeasurement table in ErWin has NOT NULL constraint for sptr_fk, =
DB does not.
Solution: Remove constraint from ErWin model.
Reason: Constraint is unecessary.

10. BlastHits table in ErWin has attributes
    usf_spc_fk
    owner_us_fk
    usf_con_fk
which do not exist in the DB.=20
Solution: Remove the attributes from the ErWin model.
Reason: The attributes are obsolete.

11. CanonicalSequenceFeature table exists in ErWin model but does not =
exist in DB.
Solution: Remove the table from the ErWin model.
Reason: CSF's are no longer supported.

12. CitationLink table in ErWin model has attributes
    es_us_fk
    es_us_con_fk
which do not exist in the DB.=20
Solution: Remove the attributes from the ErWin model.
Reason: The attributes are obsolete.

13. CSF_ExternalDBLinktable exists in ErWin model but does not exist in =
DB.
Solution: Remove the table from the ErWin model.
Reason: CSF's are no longer supported.

14. ExperimentFactors table in ErWin has attribute of measurement_units, =
DB calls this attribute factor_units.
Solution: Change the measurement_units attribute in ErWin to be =
factor_units.
Reason: ErWin attribute name does not match DB attribute name.

15. ExperimentFactors table in ErWin model has attributes
    es_us_fk
    es_us_con_fk
which do not exist in the DB.=20
Solution: Remove the attributes from the ErWin model.
Reason: The attributes are obsolete.

16. ExperimentSet table in ErWin model has NOT NULL constraint for =
archive_bundle_ref, DB does not.
Solution: Remove NOT NULL constraint from archive_bundle_ref in ErWin =
model.
Reason: Constraint is unecessary.

17. ExperimentSet table in ErWin model has attribute
    us_con_fk
which do not exist in the DB.=20
Solution: Remove the attributes from the ErWin model.
Reason: The attributes are obsolete.

18. ExperimentSet table in ErWin model has NOT NULL constraint on =
analysis_description attribute, DB does not.
Solution: remove NOT NULL constraint in ErWin model.
Reason: constraint is unecessary

19. ExperimentSet table in DB has cit_fk attribute, ErWin does not.
Solution: add cit_fk attribute to ErWin model.
Reason: attribute required.

20. ExternalDatabase table in DB has attribute of main_url, ErWin model =
has attribute of url.
Solution: change name in ErWin.
Reason: to make name consistent with DB.

21. ExternalDatabase table in DB has attribute of parameterized_url =
varchar(128), ErWin model has attribute of is_parameterized bit.
Solution: change name and type in ErWin.
Reason: to make name and type consistent with DB.

22. ExternalDatabase table in DB has NOT NULL constraint on name =
attribute, ErWin does not.
Solution: add constraint to ErWin model.
Reason: name is required.

23. HotSpots table in ErWin model has attributes
    usf_spc_Fk
    usf_con_fk
    es_us_con_fk
    es_us_fk
    usf_owner_us_fk
which do not exist in the DB.=20
Solution: Remove the attributes from the ErWin model.
Reason: The attributes are obsolete.

24. RelatedCSF table exists in ErWin, does not exist in DB.
Solution: remove RelatedCSF table from ErWin.
Reason: CSF's are no longer supported.

25. Sample table in ErWin and DB do not have a name attribute. =
Currently, the Curation Tool is using the cell_line attribute to hold =
this information. This was a hack to avoid changing DB, GeneXML, and =
translators.
Solution: Add attribute to ErWin model, DB, GeneXML, XML2DB, DB2XML and =
any other affected tools and models.
Reason: Sample needs a unique identifier field.

26. SampleProtocols table in ErWin has attribute
    smp_spc_fk
which does not exist in the DB.=20
Solution: Remove the attribute from the ErWin model.
Reason: The attribute is obsolete.

27. Scanner table in ErWin has attribute model_num, DB has attribute =
model_description.
Solution: change name in ErWin.
Reason: to make DB and ErWin consistent.

28. Species table in DB and ErWin have attribute of num_chromosomes =
which has type of char. This attribute should be int or varchar.
Solution: change the type to int in DB, ErWin, and other affected tools =
and models.
Reason: char is not sufficient to represent this attribute.

29. SpotLink table in ErWin model has attributes
    ams_am_us_fk
    als_al_con_fk
    ams_am_us_con_fk
    ams_am_primary_es_fk
    als_al_fk
    ams_am_fk
which do not exist in the DB.=20
Solution: Remove the attributes from the ErWin model.
Reason: The attributes are obsolete.

30. Spotter table in ErWin has attribute model_num, DB has attribute =
model_description.
Solution: change name in ErWin.
Reason: to make DB and ErWin consistent.

31. Spotter table in ErWin has attribute of con_pk with a NOT NULL =
constraint, DB defines this constraint as con_fk with no NOT NULL =
constraint.
Solution: rename constraint in ErWin and remove NOT NULL constraint.
Reason: name is wrong and constraint is unecessary.

32.TL_FactorValues table in ErWin model has attributes
    ratio_am_fk
    ef_es_us_con_fk
    es_us_fk
    es_us_con_fk
    es_fk
    ef_es_fk
    ef_es_us_fk
which do not exist in the DB.=20
Solution: Remove the attributes from the ErWin model.
Reason: The attributes are obsolete.

33. TL_FactorValues table in DB has attribute reference_value =
varchar(128) NOT NULL which does not exist in ErWin model.
Solution: add attribute to ErWin model.
Reason: attribute required for TBD.

34. Treatment_AMs table in ErWin has attributes of am_pk and tl_pk, DB =
calls these attributes am_fk and tl_fk, respectively.
Solution: change attribute names in ErWin.
Reason: names are incorrect.

35. Treatment_AMs table in ErWin has attributes
    primary_es_fk
    us_con_fk
    us_fk
    tl_es_fk
    tl_es_us_fk
    tl_ration_am_fk
    tl_us_con_fk
which do not exist in the DB.=20
Solution: Remove the attributes from the ErWin model.
Reason: The attributes are obsolete.

36. TreatmentLevel table in ErWin has attributes
    am_con_fk
    es_us_fk
    am_us_fk
    es_us_con_fk
    am_primary_es_fk
which do not exist in the DB.=20
Solution: Remove the attributes from the ErWin model.
Reason: The attributes are obsolete.

37. UserCanonicalLink table exists in ErWin but does not exist in DB.
Solution: remove table from ErWin.
Reason: CSF's are no longer supported.

38. UserSequenceFeature table in ErWin has NOT NULL constraints on =
nonunique_flag, con_fk and putative_csf attributes, DB does not. CSF's =
are no longer supported, so the putative_csf attribute is meaningless.
Solution: Add NOT NULL constraint to nonunique_flag in DB. Remove NOT =
NULL constraint from con_fk in ErWin model. Remove putative_csf =
attribute from DB, ErWin and all other affected tools and models.
Reason: A bit attribute (nonunique_flag) must either be true or false. =
The NOT NULL constraint on con_fk is unecessary. The putative_csf =
attribute is no longer supported since CSF's are no longer supported.

39. USF_ExternalDBLink table in ErWin has attributes
    usf_con_fk
    usf_spc_fk
    usf_owner_us_fk
which do not exist in the DB.=20
Solution: Remove the attributes from the ErWin model.
Reason: The attributes are obsolete.

Re: [GeneX-dev] Bug tracking on sourceforge

[Todd P. <tf...@nc...>]

Whatever is simplest to implement and avoids any confusion is ok with me.

----- Original Message ----- 
From: "Jason E. Stewart" <ja...@op...>
To: <gen...@li...>
Sent: Wednesday, January 31, 2001 12:06 PM
Subject: Re: [GeneX-dev] Bug tracking on sourceforge


> "Todd Peterson" <tf...@nc...> writes:
> 
> > The current bug system on SF has the priorities annotated with the
> > following:
> > 
> > 1 Lowest
> > ...
> > 5 Medium
> > ...
> > 9 Highest
> > 
> > This is opposite to the scheme below. Can we change the Lowest, Medium,
> > Highest to our own interpretations?
> 
> What do people feel. I think that 9 priorities are pointless, there
> are at least 3 that will never get used. 
> 
> Todd, if you're suggesting that we switch the SF priority scheme so
> that 1 is high and 9 is low, that might be a problem. Since that
> information is auto-generated by the SF scripts, we cannot change
> it. That means users that examine our bug list will see all theses
> priority one bugs, which sourceforge claims is *low* priority. 
> 
> Perhaps what we want is to map:
> 
> Genex                                  SourceForge
> Bugzilla:                              Bug track
> 
> P0: Critical Failure                   9:
>     Must Fix Immediately
> P1  Major Bug                          8:
>     Must fix in this release           
> P2  Important Bug                      7:
>     Fix in this release if possible    
> P3  Minor Bug                          6:
>     Fix in next release                
> P4  Minor Bug                          --
>     (redundant with P3)
> P5  Don't work on unless instructed    5: (or 1:)?
> 
> jas.
> 
> 
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev
> 

Re: [GeneX-dev] Bug tracking on sourceforge

[Harry M. <man...@ho...>]

"Jason E. Stewart" wrote:
> What do people feel. I think that 9 priorities are pointless, there
> are at least 3 that will never get used.

9 categories are useless.  Probably 6 are too many; 4 is about right, but I don't really care too much; I'll ignore all less than the top 2 :).

Re: the priority numbering inversion.  Not enough confusion to worry about.  We're big boys. We can count up as well as down.  In conversation, refer to HIGH priority vs low pri and the point will be
made.



> Todd, if you're suggesting that we switch the SF priority scheme so
> that 1 is high and 9 is low, that might be a problem. Since that
> information is auto-generated by the SF scripts, we cannot change
> it. That means users that examine our bug list will see all theses
> priority one bugs, which sourceforge claims is *low* priority.
> 
> Perhaps what we want is to map:
> 
> Genex                                  SourceForge
> Bugzilla:                              Bug track
> 
> P0: Critical Failure                   9:
>     Must Fix Immediately
> P1  Major Bug                          8:
>     Must fix in this release
> P2  Important Bug                      7:
>     Fix in this release if possible
> P3  Minor Bug                          6:
>     Fix in next release
> P4  Minor Bug                          --
>     (redundant with P3)
> P5  Don't work on unless instructed    5: (or 1:)?
> 
> jas.
> 
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev

-- 
Cheers,
Harry

Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || man...@ho...

Re: [GeneX-dev] Bug tracking on sourceforge

[<ja...@op...>]

"Todd Peterson" <tf...@nc...> writes:

> The current bug system on SF has the priorities annotated with the
> following:
> 
> 1 Lowest
> ...
> 5 Medium
> ...
> 9 Highest
> 
> This is opposite to the scheme below. Can we change the Lowest, Medium,
> Highest to our own interpretations?

What do people feel. I think that 9 priorities are pointless, there
are at least 3 that will never get used. 

Todd, if you're suggesting that we switch the SF priority scheme so
that 1 is high and 9 is low, that might be a problem. Since that
information is auto-generated by the SF scripts, we cannot change
it. That means users that examine our bug list will see all theses
priority one bugs, which sourceforge claims is *low* priority. 

Perhaps what we want is to map:

Genex                                  SourceForge
Bugzilla:                              Bug track

P0: Critical Failure                   9:
    Must Fix Immediately
P1  Major Bug                          8:
    Must fix in this release           
P2  Important Bug                      7:
    Fix in this release if possible    
P3  Minor Bug                          6:
    Fix in next release                
P4  Minor Bug                          --
    (redundant with P3)
P5  Don't work on unless instructed    5: (or 1:)?

jas.

Re: [GeneX-dev] updated SF genex page on harwin

[Greg D. C. <gd...@nc...>]

VERY nice!!! Looking good.

There are some typos and broken links. I assume you will find them, so I won't 
bother you now with that sort of edit. Let me us know when the final draft is 
ready.

I do have one comment. Can we indicate somewhere very visible to the visitor 
that this page is under construction and when it is expected to be in a stable 
form (say 1 month from now)?

Also shouldn't we be using the same GeneX logo on our SourceForge home page and 
on the genex.ncgr.org homepage? I personally don't care too much which one we 
use, but shouldn't it be the same?

Greg

>X-Authentication-Warning: tomato.inztro.com: apache set sender to 
ze...@in... using -f
>To: Harry Mangalam <man...@ho...>
>From: Jiaye Zhou <ze...@in...>
>Cc: gen...@li...
>MIME-Version: 1.0
>Content-Transfer-Encoding: 8bit
>User-Agent: IMP/PHP IMAP webmail program 2.2.3
>X-Originating-IP: 192.168.0.9
>Subject: [GeneX-dev] updated SF genex page on harwin
>Date: Tue, 30 Jan 2001 17:58:34 -0700 (MST)
>
>
>Hi Harry,
>
>  I just went ahead and changed the single page into server side included 
pages.
>I checked on Sourceforge, they support ssi with extension shtml. The new page 
is 
>called index2.shtml ( http://24.1.175.29/sf/index2.shtml ). I also included the 
>new banner image. I put the image in the "img" folder and created a "content" 
>folder for placing the included files. (menu.ssi and main.ssi for now). Please 
>take a look and double check that nothing is broken.
>
>Jiaye
>
>_______________________________________________
>Genex-dev mailing list
>Gen...@li...
>http://lists.sourceforge.net/lists/listinfo/genex-dev

Re: [GeneX-dev] [Q]: GeneXML <==> Curation Tool

[Todd P. <tf...@nc...>]

I suggest that it be an optional component of the control bundle. A command
line switch or a config file or something could control this option (and any
other options). Like I said before, the CT should be used to edit all DB
information...including groups. The screen is in the CT to do this. Edits
aren't available yet.

----- Original Message -----
From: "Greg D. Colello" <gd...@nc...>
To: <gen...@li...>
Sent: Wednesday, January 31, 2001 8:35 AM
Subject: Re: [GeneX-dev] [Q]: GeneXML <==> Curation Tool


> No problem here.
>
> Greg
>
> >Delivered-To: fix...@li...@fixme
> >To: gen...@li...
> >Mime-Version: 1.0 (generated by tm-edit 1.5)
> >From: ja...@op... (Jason E. Stewart)
> >Subject: [GeneX-dev] [Q]: GeneXML <==> Curation Tool
> >Date: 30 Jan 2001 09:04:17 -0700
> >
> >Hey,
> >
> >In the control-bundle we ship a list of the current groups in the
> >GroupSec table. With each groups comes a list of that groups
> >members. It turns out that this is a problem for the new XML API.
> >
> >I doubt that the CT is actually using this group information for
> >anything, is it? I would like to remove that information completely
> >from the control-bundle. Although it is not a security risk (we are
> >not giving out login names or passwords) it is not anyone's business
> >who is currently registered as a user with NCGR, and so it shouldn't
> >go out in the control-bundle.
> >
> >The problem that I would like to fix is that currently the group
> >members are listed by their contact fkey, and not by their usersec
> >fkey. I want to use the XML API to do updates of the DB, and I need it
> >to accurately reflect the state of the DB, so an update of the
> >GroupSec/UserSec information is only possible if that info is stored
> >in GeneXML.
> >
> >jas.
> >
> >_______________________________________________
> >Genex-dev mailing list
> >Gen...@li...
> >http://lists.sourceforge.net/lists/listinfo/genex-dev
>
>
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev
>

Re: [GeneX-dev] Bug tracking on sourceforge

[Todd P. <tf...@nc...>]

The current bug system on SF has the priorities annotated with the
following:

1 Lowest
...
5 Medium
...
9 Highest

This is opposite to the scheme below. Can we change the Lowest, Medium,
Highest to our own interpretations?

>
> >PPS. We should agree on guidelines for what priorities P1-5 mean, as
> >well as what the severities 'critical' -> 'enhancement' mean. If too
> >much stuff gets filed as P1, then it means nothing. How about:
> >
> >P1: fix should be in place by end of week
> >P2: fix in place within 10 business days
> >P3: fix in place by next release
> >P4: fix by release after-next
> >P5: no date
> >
> >This way the default is P3, and if we file with P1 or P2, it's
> >important to do it *soon*.
> >
>

Re: [GeneX-dev] [Q]: GeneXML <==> Curation Tool

[Greg D. C. <gd...@nc...>]

No problem here.

Greg

>Delivered-To: fix...@li...@fixme
>To: gen...@li...
>Mime-Version: 1.0 (generated by tm-edit 1.5)
>From: ja...@op... (Jason E. Stewart)
>Subject: [GeneX-dev] [Q]: GeneXML <==> Curation Tool
>Date: 30 Jan 2001 09:04:17 -0700
>
>Hey,
>
>In the control-bundle we ship a list of the current groups in the
>GroupSec table. With each groups comes a list of that groups
>members. It turns out that this is a problem for the new XML API.
>
>I doubt that the CT is actually using this group information for
>anything, is it? I would like to remove that information completely
>from the control-bundle. Although it is not a security risk (we are
>not giving out login names or passwords) it is not anyone's business
>who is currently registered as a user with NCGR, and so it shouldn't
>go out in the control-bundle.
>
>The problem that I would like to fix is that currently the group
>members are listed by their contact fkey, and not by their usersec
>fkey. I want to use the XML API to do updates of the DB, and I need it
>to accurately reflect the state of the DB, so an update of the
>GroupSec/UserSec information is only possible if that info is stored
>in GeneXML.
>
>jas.
>
>_______________________________________________
>Genex-dev mailing list
>Gen...@li...
>http://lists.sourceforge.net/lists/listinfo/genex-dev