gusdev-gusdev — Topics concerning GUS development

Re: [GUSDEV] PK constraints for version tables

[<pi...@pc...>]

The date format was modified (precision increased) and the problem persisted).

The version tables are useful for a few reasons:
1) Rows can be restored that were updated or deleted in error.
2) There is a record of who, when, and how a row was updated or deleted.

Restoration can be accomplished using the alg_inv_id and as long as the 
user_id
and version modification and original modification date are available, the
modifications can be tracked.

I'd like to point out that the version tables are rarely used.

Quoting Steve Fischer <sfi...@pc...>:

> the "race" condition we have is that a single process is rapidly 
> updating a row in time that is less than the resolution of our 
> current date stamp.  we won't be able to distinguish them by 
> row_alg_invocation_id as they are done by the same process.  it it 
> likely but not assured that an increase in resolution will solve the 
> problem. i propose that we:
>  1. increase the precision
>  2. drop the constraint
>  3. don't really care too much
>
> if we want to care, then, i suppose, we would have to add another 
> column to the version tables that was an increasing sequence.
>
> steve
>
>
> Chris Sarnowski wrote:
>
>> I was going to suggest (2) below, but will nitpick and point out 
>> that  it would make the problem 1000 times less likely to occur, but 
>> that  it's still possible to have collisions, especially if, say, 2  
>> processes are simultaneously working on overlapping data.
>> With (1), the problem is that with any collision, there is the  
>> possibility that you won't be able to determine in what order 
>> changes  were made to data (which could, for example, break an 
>> automated  "rollback" system). Given that collisions are probably 
>> already rare,  and that algorithm_invocation_id helps distinguish 
>> simultaneous  processes, this just may not be an important problem.
>> So (1) is still the easiest workaround, and I'd guess "good enough".
>> -Chris
>>
>>
>> On Oct 21, 2005, at 3:44 PM, Angel Pizarro wrote:
>>
>>> Debbie's point is that uniqueness in version tables doesn't really  
>>> matter and it is getting in the way of fast inserts. The only ways  
>>> to fix this are:
>>>
>>> 1) drop the constraints
>>> 2) increase the precision of row_modification_date to milliseconds.
>>>
>>> -angel
>>>
>>> msa...@pc... wrote:
>>>
>>>
>>>>
>>>>
>>>> The problem with that is that the ID alone isn't necessarily  
>>>> unique-- a row that
>>>> has been edited multiple times will end up in the version table  
>>>> multiple times,
>>>> hence the addition of the modification_date to (attempt to) ensure 
>>>>  uniqueness.
>>>>
>>>> --Mike
>>>>
>>>> Quoting Steve Fischer <sfi...@pc...>:
>>>>
>>>>
>>>>> yes, i guess so.
>>>>>
>>>>> steve
>>>>>
>>>>> Deborah Pinney wrote:
>>>>>
>>>>>
>>>>>> You mean drop the uniqueness constraint for the original PK 
>>>>>> +modification_date?
>>>>>> Steve Fischer wrote:
>>>>>>
>>>>>>
>>>>>>> how about just dropping the uniqueness constraint of the  
>>>>>>> modification date?
>>>>>>>
>>>>>>> steve
>>>>>>>
>>>>>>> Chris Sarnowski wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> I can't speak for GUS needs in this particular case, but I've  
>>>>>>>> had the  same issue in other systems. Deborah is correct in  
>>>>>>>> that these fields  are not right for PK. The question is how  
>>>>>>>> important it is to preserve  exact order of the changes to the 
>>>>>>>>  data. If it's not critical you  could just drop the PK. If it 
>>>>>>>>  is (or even if it's not but you believe  in the rule "every  
>>>>>>>> table must have a PK"), then you should use a  surrogate key  
>>>>>>>> from a sequence. In practice, at least, the sequence  values  
>>>>>>>> increase monotonically so changes to a record that occur   
>>>>>>>> multiple times with the same modification date can still be  
>>>>>>>> ordered  correctly.
>>>>>>>> I prefer the latter, in general, but I suppose adding a new  
>>>>>>>> surrogate  key field to all version tables in GUS would be a  
>>>>>>>> pretty big deal.
>>>>>>>>
>>>>>>>> Just my thoughts.
>>>>>>>> -Chris Sarnowski
>>>>>>>>
>>>>>>>> On Oct 21, 2005, at 11:07 AM, Deborah Pinney wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> I suggest that we drop the uniqueness constraint for PKs of  
>>>>>>>>> version  tables. PKs for these tables consist of the original 
>>>>>>>>>  PK and the  modification date. Rapid computation can result  
>>>>>>>>> in uniqueness  copnstraint violations that are not remedied  
>>>>>>>>> by date format  changes. There doesn't seem to be a purpose  
>>>>>>>>> in having these  constraints for any of the version tables  
>>>>>>>>> and dropping the  constraints would not result in the loss of 
>>>>>>>>>  information or change  query results. I don't know if there  
>>>>>>>>> is implicit indexing on these  keys but I wonder if this  
>>>>>>>>> could be handled using explicit indexing.
>>>>>>>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads, discussions,
>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>

Re: [GUSDEV] PK constraints for version tables

[Steve F. <sfi...@pc...>]

the "race" condition we have is that a single process is rapidly 
updating a row in time that is less than the resolution of our current 
date stamp.  we won't be able to distinguish them by 
row_alg_invocation_id as they are done by the same process.  it it 
likely but not assured that an increase in resolution will solve the 
problem. 

i propose that we:
  1. increase the precision
  2. drop the constraint
  3. don't really care too much

if we want to care, then, i suppose, we would have to add another column 
to the version tables that was an increasing sequence.

steve


Chris Sarnowski wrote:

> I was going to suggest (2) below, but will nitpick and point out that  
> it would make the problem 1000 times less likely to occur, but that  
> it's still possible to have collisions, especially if, say, 2  
> processes are simultaneously working on overlapping data.
> With (1), the problem is that with any collision, there is the  
> possibility that you won't be able to determine in what order changes  
> were made to data (which could, for example, break an automated  
> "rollback" system). Given that collisions are probably already rare,  
> and that algorithm_invocation_id helps distinguish simultaneous  
> processes, this just may not be an important problem.
> So (1) is still the easiest workaround, and I'd guess "good enough".
> -Chris
>
>
> On Oct 21, 2005, at 3:44 PM, Angel Pizarro wrote:
>
>> Debbie's point is that uniqueness in version tables doesn't really  
>> matter and it is getting in the way of fast inserts. The only ways  
>> to fix this are:
>>
>> 1) drop the constraints
>> 2) increase the precision of row_modification_date to milliseconds.
>>
>> -angel
>>
>> msa...@pc... wrote:
>>
>>
>>>
>>>
>>> The problem with that is that the ID alone isn't necessarily  
>>> unique-- a row that
>>> has been edited multiple times will end up in the version table  
>>> multiple times,
>>> hence the addition of the modification_date to (attempt to) ensure  
>>> uniqueness.
>>>
>>> --Mike
>>>
>>> Quoting Steve Fischer <sfi...@pc...>:
>>>
>>>
>>>> yes, i guess so.
>>>>
>>>> steve
>>>>
>>>> Deborah Pinney wrote:
>>>>
>>>>
>>>>> You mean drop the uniqueness constraint for the original PK 
>>>>> +modification_date?
>>>>> Steve Fischer wrote:
>>>>>
>>>>>
>>>>>> how about just dropping the uniqueness constraint of the  
>>>>>> modification date?
>>>>>>
>>>>>> steve
>>>>>>
>>>>>> Chris Sarnowski wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I can't speak for GUS needs in this particular case, but I've  
>>>>>>> had the  same issue in other systems. Deborah is correct in  
>>>>>>> that these fields  are not right for PK. The question is how  
>>>>>>> important it is to preserve  exact order of the changes to the  
>>>>>>> data. If it's not critical you  could just drop the PK. If it  
>>>>>>> is (or even if it's not but you believe  in the rule "every  
>>>>>>> table must have a PK"), then you should use a  surrogate key  
>>>>>>> from a sequence. In practice, at least, the sequence  values  
>>>>>>> increase monotonically so changes to a record that occur   
>>>>>>> multiple times with the same modification date can still be  
>>>>>>> ordered  correctly.
>>>>>>> I prefer the latter, in general, but I suppose adding a new  
>>>>>>> surrogate  key field to all version tables in GUS would be a  
>>>>>>> pretty big deal.
>>>>>>>
>>>>>>> Just my thoughts.
>>>>>>> -Chris Sarnowski
>>>>>>>
>>>>>>> On Oct 21, 2005, at 11:07 AM, Deborah Pinney wrote:
>>>>>>>
>>>>>>>
>>>>>>>> I suggest that we drop the uniqueness constraint for PKs of  
>>>>>>>> version  tables. PKs for these tables consist of the original  
>>>>>>>> PK and the  modification date. Rapid computation can result  in 
>>>>>>>> uniqueness  copnstraint violations that are not remedied  by 
>>>>>>>> date format  changes. There doesn't seem to be a purpose  in 
>>>>>>>> having these  constraints for any of the version tables  and 
>>>>>>>> dropping the  constraints would not result in the loss of  
>>>>>>>> information or change  query results. I don't know if there  is 
>>>>>>>> implicit indexing on these  keys but I wonder if this  could be 
>>>>>>>> handled using explicit indexing.
>>>>>>>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Re: [GUSDEV] PK constraints for version tables

[Chris S. <csa...@pc...>]

I was going to suggest (2) below, but will nitpick and point out that  
it would make the problem 1000 times less likely to occur, but that  
it's still possible to have collisions, especially if, say, 2  
processes are simultaneously working on overlapping data.
With (1), the problem is that with any collision, there is the  
possibility that you won't be able to determine in what order changes  
were made to data (which could, for example, break an automated  
"rollback" system). Given that collisions are probably already rare,  
and that algorithm_invocation_id helps distinguish simultaneous  
processes, this just may not be an important problem.
So (1) is still the easiest workaround, and I'd guess "good enough".
-Chris


On Oct 21, 2005, at 3:44 PM, Angel Pizarro wrote:

> Debbie's point is that uniqueness in version tables doesn't really  
> matter and it is getting in the way of fast inserts. The only ways  
> to fix this are:
>
> 1) drop the constraints
> 2) increase the precision of row_modification_date to milliseconds.
>
> -angel
>
> msa...@pc... wrote:
>
>
>>
>>
>> The problem with that is that the ID alone isn't necessarily  
>> unique-- a row that
>> has been edited multiple times will end up in the version table  
>> multiple times,
>> hence the addition of the modification_date to (attempt to) ensure  
>> uniqueness.
>>
>> --Mike
>>
>> Quoting Steve Fischer <sfi...@pc...>:
>>
>>
>>> yes, i guess so.
>>>
>>> steve
>>>
>>> Deborah Pinney wrote:
>>>
>>>
>>>> You mean drop the uniqueness constraint for the original PK 
>>>> +modification_date?
>>>> Steve Fischer wrote:
>>>>
>>>>
>>>>> how about just dropping the uniqueness constraint of the  
>>>>> modification date?
>>>>>
>>>>> steve
>>>>>
>>>>> Chris Sarnowski wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> I can't speak for GUS needs in this particular case, but I've  
>>>>>> had the  same issue in other systems. Deborah is correct in  
>>>>>> that these fields  are not right for PK. The question is how  
>>>>>> important it is to preserve  exact order of the changes to the  
>>>>>> data. If it's not critical you  could just drop the PK. If it  
>>>>>> is (or even if it's not but you believe  in the rule "every  
>>>>>> table must have a PK"), then you should use a  surrogate key  
>>>>>> from a sequence. In practice, at least, the sequence  values  
>>>>>> increase monotonically so changes to a record that occur   
>>>>>> multiple times with the same modification date can still be  
>>>>>> ordered  correctly.
>>>>>> I prefer the latter, in general, but I suppose adding a new  
>>>>>> surrogate  key field to all version tables in GUS would be a  
>>>>>> pretty big deal.
>>>>>>
>>>>>> Just my thoughts.
>>>>>> -Chris Sarnowski
>>>>>>
>>>>>> On Oct 21, 2005, at 11:07 AM, Deborah Pinney wrote:
>>>>>>
>>>>>>
>>>>>>> I suggest that we drop the uniqueness constraint for PKs of  
>>>>>>> version  tables. PKs for these tables consist of the original  
>>>>>>> PK and the  modification date. Rapid computation can result  
>>>>>>> in uniqueness  copnstraint violations that are not remedied  
>>>>>>> by date format  changes. There doesn't seem to be a purpose  
>>>>>>> in having these  constraints for any of the version tables  
>>>>>>> and dropping the  constraints would not result in the loss of  
>>>>>>> information or change  query results. I don't know if there  
>>>>>>> is implicit indexing on these  keys but I wonder if this  
>>>>>>> could be handled using explicit indexing.

Re: [GUSDEV] PK constraints for version tables

[Angel P. <an...@ma...>]

Debbie's point is that uniqueness in version tables doesn't really 
matter and it is getting in the way of fast inserts. The only ways to 
fix this are:

1) drop the constraints
2) increase the precision of row_modification_date to milliseconds.

-angel

msa...@pc... wrote:

>
>
> The problem with that is that the ID alone isn't necessarily unique-- 
> a row that
> has been edited multiple times will end up in the version table 
> multiple times,
> hence the addition of the modification_date to (attempt to) ensure 
> uniqueness.
>
> --Mike
>
> Quoting Steve Fischer <sfi...@pc...>:
>
>> yes, i guess so.
>>
>> steve
>>
>> Deborah Pinney wrote:
>>
>>> You mean drop the uniqueness constraint for the original 
>>> PK+modification_date?
>>> Steve Fischer wrote:
>>>
>>>> how about just dropping the uniqueness constraint of the 
>>>> modification date?
>>>>
>>>> steve
>>>>
>>>> Chris Sarnowski wrote:
>>>>
>>>>>
>>>>> I can't speak for GUS needs in this particular case, but I've had 
>>>>> the  same issue in other systems. Deborah is correct in that these 
>>>>> fields  are not right for PK. The question is how important it is 
>>>>> to preserve  exact order of the changes to the data. If it's not 
>>>>> critical you  could just drop the PK. If it is (or even if it's 
>>>>> not but you believe  in the rule "every table must have a PK"), 
>>>>> then you should use a  surrogate key from a sequence. In practice, 
>>>>> at least, the sequence  values increase monotonically so changes 
>>>>> to a record that occur  multiple times with the same modification 
>>>>> date can still be ordered  correctly.
>>>>> I prefer the latter, in general, but I suppose adding a new 
>>>>> surrogate  key field to all version tables in GUS would be a 
>>>>> pretty big deal.
>>>>>
>>>>> Just my thoughts.
>>>>> -Chris Sarnowski
>>>>>
>>>>> On Oct 21, 2005, at 11:07 AM, Deborah Pinney wrote:
>>>>>
>>>>>> I suggest that we drop the uniqueness constraint for PKs of 
>>>>>> version  tables. PKs for these tables consist of the original PK 
>>>>>> and the  modification date. Rapid computation can result in 
>>>>>> uniqueness  copnstraint violations that are not remedied by date 
>>>>>> format  changes. There doesn't seem to be a purpose in having 
>>>>>> these  constraints for any of the version tables and dropping the 
>>>>>>  constraints would not result in the loss of information or 
>>>>>> change  query results. I don't know if there is implicit indexing 
>>>>>> on these  keys but I wonder if this could be handled using 
>>>>>> explicit indexing.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This SF.Net email is sponsored by:
>>>>> Power Architecture Resource Center: Free content, downloads, 
>>>>> discussions,
>>>>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>>>>> _______________________________________________
>>>>> Gusdev-gusdev mailing list
>>>>> Gus...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by:
>>>> Power Architecture Resource Center: Free content, downloads, 
>>>> discussions,
>>>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>>>> _______________________________________________
>>>> Gusdev-gusdev mailing list
>>>> Gus...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by:
>>> Power Architecture Resource Center: Free content, downloads, 
>>> discussions,
>>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>>> _______________________________________________
>>> Gusdev-gusdev mailing list
>>> Gus...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads, 
>> discussions,
>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev



-- 

Angel Pizarro
Director, Bioinformatics Facility
Institute for Translational Medicine and Therapeutics
University of Pennsylvania
806 BRB II/III
421 Curie Blvd.
Philadelphia, PA 19104-6160

P: 215-573-3736
F: 215-573-9004

Re: [GUSDEV] PK constraints for version tables

[<msa...@pc...>]

The problem with that is that the ID alone isn't necessarily unique-- a 
row that
has been edited multiple times will end up in the version table 
multiple times,
hence the addition of the modification_date to (attempt to) ensure uniqueness.

--Mike

Quoting Steve Fischer <sfi...@pc...>:

> yes, i guess so.
>
> steve
>
> Deborah Pinney wrote:
>
>> You mean drop the uniqueness constraint for the original 
>> PK+modification_date?
>> Steve Fischer wrote:
>>
>>> how about just dropping the uniqueness constraint of the modification date?
>>>
>>> steve
>>>
>>> Chris Sarnowski wrote:
>>>
>>>>
>>>> I can't speak for GUS needs in this particular case, but I've had 
>>>> the  same issue in other systems. Deborah is correct in that these 
>>>> fields  are not right for PK. The question is how important it is 
>>>> to preserve  exact order of the changes to the data. If it's not 
>>>> critical you  could just drop the PK. If it is (or even if it's 
>>>> not but you believe  in the rule "every table must have a PK"), 
>>>> then you should use a  surrogate key from a sequence. In practice, 
>>>> at least, the sequence  values increase monotonically so changes 
>>>> to a record that occur  multiple times with the same modification 
>>>> date can still be ordered  correctly.
>>>> I prefer the latter, in general, but I suppose adding a new 
>>>> surrogate  key field to all version tables in GUS would be a 
>>>> pretty big deal.
>>>>
>>>> Just my thoughts.
>>>> -Chris Sarnowski
>>>>
>>>> On Oct 21, 2005, at 11:07 AM, Deborah Pinney wrote:
>>>>
>>>>> I suggest that we drop the uniqueness constraint for PKs of 
>>>>> version  tables. PKs for these tables consist of the original PK 
>>>>> and the  modification date. Rapid computation can result in 
>>>>> uniqueness  copnstraint violations that are not remedied by date 
>>>>> format  changes. There doesn't seem to be a purpose in having 
>>>>> these  constraints for any of the version tables and dropping the 
>>>>>  constraints would not result in the loss of information or 
>>>>> change  query results. I don't know if there is implicit indexing 
>>>>> on these  keys but I wonder if this could be handled using 
>>>>> explicit indexing.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by:
>>>> Power Architecture Resource Center: Free content, downloads, discussions,
>>>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>>>> _______________________________________________
>>>> Gusdev-gusdev mailing list
>>>> Gus...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by:
>>> Power Architecture Resource Center: Free content, downloads, discussions,
>>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>>> _______________________________________________
>>> Gusdev-gusdev mailing list
>>> Gus...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads, discussions,
>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>

Re: [GUSDEV] PK constraints for version tables

[Steve F. <sfi...@pc...>]

yes, i guess so.

steve

Deborah Pinney wrote:

> You mean drop the uniqueness constraint for the original 
> PK+modification_date?
> Steve Fischer wrote:
>
>> how about just dropping the uniqueness constraint of the modification 
>> date?
>>
>> steve
>>
>> Chris Sarnowski wrote:
>>
>>>
>>> I can't speak for GUS needs in this particular case, but I've had 
>>> the  same issue in other systems. Deborah is correct in that these 
>>> fields  are not right for PK. The question is how important it is to 
>>> preserve  exact order of the changes to the data. If it's not 
>>> critical you  could just drop the PK. If it is (or even if it's not 
>>> but you believe  in the rule "every table must have a PK"), then you 
>>> should use a  surrogate key from a sequence. In practice, at least, 
>>> the sequence  values increase monotonically so changes to a record 
>>> that occur  multiple times with the same modification date can still 
>>> be ordered  correctly.
>>> I prefer the latter, in general, but I suppose adding a new 
>>> surrogate  key field to all version tables in GUS would be a pretty 
>>> big deal.
>>>
>>> Just my thoughts.
>>> -Chris Sarnowski
>>>
>>> On Oct 21, 2005, at 11:07 AM, Deborah Pinney wrote:
>>>
>>>> I suggest that we drop the uniqueness constraint for PKs of 
>>>> version  tables. PKs for these tables consist of the original PK 
>>>> and the  modification date. Rapid computation can result in 
>>>> uniqueness  copnstraint violations that are not remedied by date 
>>>> format  changes. There doesn't seem to be a purpose in having 
>>>> these  constraints for any of the version tables and dropping the  
>>>> constraints would not result in the loss of information or change  
>>>> query results. I don't know if there is implicit indexing on these  
>>>> keys but I wonder if this could be handled using explicit indexing.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by:
>>> Power Architecture Resource Center: Free content, downloads, 
>>> discussions,
>>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>>> _______________________________________________
>>> Gusdev-gusdev mailing list
>>> Gus...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads, 
>> discussions,
>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Re: [GUSDEV] PK constraints for version tables

[Deborah P. <pi...@pc...>]

You mean drop the uniqueness constraint for the original 
PK+modification_date? 

Steve Fischer wrote:

> how about just dropping the uniqueness constraint of the modification 
> date?
>
> steve
>
> Chris Sarnowski wrote:
>
>>
>> I can't speak for GUS needs in this particular case, but I've had 
>> the  same issue in other systems. Deborah is correct in that these 
>> fields  are not right for PK. The question is how important it is to 
>> preserve  exact order of the changes to the data. If it's not 
>> critical you  could just drop the PK. If it is (or even if it's not 
>> but you believe  in the rule "every table must have a PK"), then you 
>> should use a  surrogate key from a sequence. In practice, at least, 
>> the sequence  values increase monotonically so changes to a record 
>> that occur  multiple times with the same modification date can still 
>> be ordered  correctly.
>> I prefer the latter, in general, but I suppose adding a new 
>> surrogate  key field to all version tables in GUS would be a pretty 
>> big deal.
>>
>> Just my thoughts.
>> -Chris Sarnowski
>>
>> On Oct 21, 2005, at 11:07 AM, Deborah Pinney wrote:
>>
>>> I suggest that we drop the uniqueness constraint for PKs of version  
>>> tables. PKs for these tables consist of the original PK and the  
>>> modification date. Rapid computation can result in uniqueness  
>>> copnstraint violations that are not remedied by date format  
>>> changes. There doesn't seem to be a purpose in having these  
>>> constraints for any of the version tables and dropping the  
>>> constraints would not result in the loss of information or change  
>>> query results. I don't know if there is implicit indexing on these  
>>> keys but I wonder if this could be handled using explicit indexing.
>>
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads, 
>> discussions,
>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Re: [GUSDEV] PK constraints for version tables

[Steve F. <sfi...@pc...>]

how about just dropping the uniqueness constraint of the modification date?

steve

Chris Sarnowski wrote:

>
> I can't speak for GUS needs in this particular case, but I've had the  
> same issue in other systems. Deborah is correct in that these fields  
> are not right for PK. The question is how important it is to preserve  
> exact order of the changes to the data. If it's not critical you  
> could just drop the PK. If it is (or even if it's not but you believe  
> in the rule "every table must have a PK"), then you should use a  
> surrogate key from a sequence. In practice, at least, the sequence  
> values increase monotonically so changes to a record that occur  
> multiple times with the same modification date can still be ordered  
> correctly.
> I prefer the latter, in general, but I suppose adding a new surrogate  
> key field to all version tables in GUS would be a pretty big deal.
>
> Just my thoughts.
> -Chris Sarnowski
>
> On Oct 21, 2005, at 11:07 AM, Deborah Pinney wrote:
>
>> I suggest that we drop the uniqueness constraint for PKs of version  
>> tables. PKs for these tables consist of the original PK and the  
>> modification date. Rapid computation can result in uniqueness  
>> copnstraint violations that are not remedied by date format  changes. 
>> There doesn't seem to be a purpose in having these  constraints for 
>> any of the version tables and dropping the  constraints would not 
>> result in the loss of information or change  query results. I don't 
>> know if there is implicit indexing on these  keys but I wonder if 
>> this could be handled using explicit indexing.
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Re: [GUSDEV] PK constraints for version tables

[Chris S. <csa...@pc...>]

I can't speak for GUS needs in this particular case, but I've had the  
same issue in other systems. Deborah is correct in that these fields  
are not right for PK. The question is how important it is to preserve  
exact order of the changes to the data. If it's not critical you  
could just drop the PK. If it is (or even if it's not but you believe  
in the rule "every table must have a PK"), then you should use a  
surrogate key from a sequence. In practice, at least, the sequence  
values increase monotonically so changes to a record that occur  
multiple times with the same modification date can still be ordered  
correctly.
I prefer the latter, in general, but I suppose adding a new surrogate  
key field to all version tables in GUS would be a pretty big deal.

Just my thoughts.
-Chris Sarnowski

On Oct 21, 2005, at 11:07 AM, Deborah Pinney wrote:
> I suggest that we drop the uniqueness constraint for PKs of version  
> tables. PKs for these tables consist of the original PK and the  
> modification date. Rapid computation can result in uniqueness  
> copnstraint violations that are not remedied by date format  
> changes. There doesn't seem to be a purpose in having these  
> constraints for any of the version tables and dropping the  
> constraints would not result in the loss of information or change  
> query results. I don't know if there is implicit indexing on these  
> keys but I wonder if this could be handled using explicit indexing.

[GUSDEV] PK constraints for version tables

[Deborah P. <pi...@pc...>]

I suggest that we drop the uniqueness constraint for PKs of version 
tables. PKs for these tables consist of the original PK and the 
modification date. Rapid computation can result in uniqueness 
copnstraint violations that are not remedied by date format changes. 
There doesn't seem to be a purpose in having these constraints for any 
of the version tables and dropping the constraints would not result in 
the loss of information or change query results. I don't know if there 
is implicit indexing on these keys but I wonder if this could be handled 
using explicit indexing.

Re: [GUSDEV] windows

[Angel P. <an...@ma...>]

Hi Chris,

I took a quick stab at this, using Cygwin, and basically found that one 
would need to change the ant build.xml files to use arch-independent 
paths (I think there is an ant tag for specifying this, but no promises 
about that) and change the build.pl script query for the architecture 
and OS and then use a properly formatted system call to ant.

I made some progress, but gave up after an afternoon, since I had much 
higher priorities than this. Unfortunately it looks like I overwrote my 
work so I can't attach the changes that I had made, but there are two 
things that put me on the right path. One was an undocumented arg to 
build "returnErrStatus" and the other was uncommenting line 41 in 
build.pl to see what the actual ant system call was:

$ build  GUS install -append -returnErrStatus

ant -f /home/angel/project_home/GUS/project_home/install/build.xml 
install -lib /home/angel/project_home/GUS/project_home/install/config 
-Dproj=GUS -DtargetDir=/home/angel/project_home/GUS/gus_home -Dcomp= 
-DgusConfigFile=/home/angel/project_home/GUS/gus_home/config/gus.config 
-DprojectsDir=/home/angel/project_home/GUS/project_home    
-Dappend=true   -logger org.apache.tools.ant.NoBannerLogger

Buildfile: \home\angel\project_home\GUS\project_home\install\build.xml 
does not exist!
Build failed

So if you can create sensible ant files that will work on both windows 
and unix, and be able to find out how to get the correct path for the 
ant system call, you should be in business! Hope that helps!
angel

Chris Topinka wrote:

> Does anyone have a way of installing the GUS schema on Oracle running 
> on windows XP.  If not, what would need to be changed to do this?  
> What about the application layer - making it windows compatible.
>
> Thanks,
>
> Chris
>
> -- 
> Christopher M. Topinka
> NLM-BHIRT Predoctoral Fellow in Computer Science
> 113 Life Sciences Center
> University of Missouri
> Columbia, MO 65211
> (573)-823-0616
> cmt...@mi... <mailto:cmt...@mi...> 



-- 

Angel Pizarro
Director, Bioinformatics Facility
Institute for Translational Medicine and Therapeutics
University of Pennsylvania
806 BRB II/III
421 Curie Blvd.
Philadelphia, PA 19104-6160

P: 215-573-3736
F: 215-573-9004

Re: [GUSDEV] windows

[Chris T. <cmt...@gm...>]

Great, thanks.

On 10/20/05, Michael Saffitz <msa...@pc...> wrote:
>
>
> Hi Chris,
>
> Oracle on Windows shouldn't be a problem... The app framework connects to
> Oracle using JDBC and DBD::Oracle (perl), so if that's available, the hos=
t
> server/system that's running Oracle (or Postgres for that matter) isn't
> relevant.
>
> The App Framework may theoretically run on Windows under cygwin, and I
> believe Angel Pizzaro attempted this, but ran into problems. I'm not sure
> if he ever overcame them. I wouldn't recommend trying it on Windows... It
> will likely be a large effort.
>
> --Mike
>
> On 10/20/05 2:50 PM, "Chris Topinka" <cmt...@gm...> wrote:
>
> > Does anyone have a way of installing the GUS schema on Oracle running o=
n
> > windows XP. If not, what would need to be changed to do this? What abou=
t
> the
> > application layer - making it windows compatible.
> >
> > Thanks,
> >
> > Chris
> >
> > --
> > Christopher M. Topinka
> > NLM-BHIRT Predoctoral Fellow in Computer Science
> > 113 Life Sciences Center
> > University of Missouri
> > Columbia, MO 65211
> > (573)-823-0616
> > cmt...@mi...
>
>
>


--
Christopher M. Topinka
NLM-BHIRT Predoctoral Fellow in Computer Science
113 Life Sciences Center
University of Missouri
Columbia, MO 65211
(573)-823-0616
cmt...@mi...

Re: [GUSDEV] windows

[Michael S. <msa...@pc...>]

Hi Chris,

Oracle on Windows shouldn't be a problem... The app framework connects to
Oracle using JDBC and DBD::Oracle (perl), so if that's available, the host
server/system that's running Oracle (or Postgres for that matter) isn't
relevant.

The App Framework may theoretically run on Windows under cygwin, and I
believe Angel Pizzaro attempted this, but ran into problems.  I'm not sure
if he ever overcame them.  I wouldn't recommend trying it on Windows... It
will likely be a large effort.

--Mike

On 10/20/05 2:50 PM, "Chris Topinka" <cmt...@gm...> wrote:

> Does anyone have a way of installing the GUS schema on Oracle running on
> windows XP. If not, what would need to be changed to do this? What about the
> application layer - making it windows compatible.
> 
> Thanks,
> 
> Chris
> 
> --
> Christopher M. Topinka
> NLM-BHIRT Predoctoral Fellow in Computer Science
> 113 Life Sciences Center
> University of Missouri
> Columbia, MO 65211
> (573)-823-0616
> cmt...@mi...

Re: [GUSDEV] windows

[Steve F. <sfi...@pc...>]

chris-

sorry, this isn't supported.    GUS is fundamentally a unix application. 

steve

Chris Topinka wrote:

> Does anyone have a way of installing the GUS schema on Oracle running 
> on windows XP.  If not, what would need to be changed to do this?  
> What about the application layer - making it windows compatible.
>
> Thanks,
>
> Chris
>
> -- 
> Christopher M. Topinka
> NLM-BHIRT Predoctoral Fellow in Computer Science
> 113 Life Sciences Center
> University of Missouri
> Columbia, MO 65211
> (573)-823-0616
> cmt...@mi... <mailto:cmt...@mi...> 

[GUSDEV] windows

[Chris T. <cmt...@gm...>]

Does anyone have a way of installing the GUS schema on Oracle running on
windows XP. If not, what would need to be changed to do this? What about th=
e
application layer - making it windows compatible.

Thanks,

Chris

--
Christopher M. Topinka
NLM-BHIRT Predoctoral Fellow in Computer Science
113 Life Sciences Center
University of Missouri
Columbia, MO 65211
(573)-823-0616
cmt...@mi...

Re: [GUSDEV] question about coding in LoadSequenceFeatures.pm

[Angel P. <an...@ma...>]

Actually, I don't think so, since the AAFeature and NAFeature tables 
differ in a few respects. With respect to ExternalAASequence you may be 
OK, but I think you will run into problems if you try to add any features.

As a side note, why are the AAFeature and NAFeature tables different? I 
don't see any documentation using the schema browser on any of the AASeq 
or AAFeat table columns, so I can't make a good assesment as to what is 
needed when. Is NAFeature going to move to the feature_name_id FK to 
DoTS::FeatureName (as opposed to a string column) scheme like AAFeature 
at any point?

Thanks,
Angel


Steve Fischer wrote:

> yes.
>
> -steve
>
> Weichen Wu wrote:
>
>> My question is about submit() method. In LoadSequenceFeatures.pm, 
>> there is one line
>>    $naSequence->submit();
>> Does the submit method do the actual insertion into the 
>> ExternalNASequence table?
>>
>> If I change variable $nasequence to $AAsequence, declare it as
>> $aaSequence = GUS::Model::DoTS::ExternalAASequence( ), then set up 
>> $aaSequence->sequenceID and taxonid and etc, finally run
>> $aaSequence->submit();
>> Will it insert a record to ExternalAASequence( )?
>>
>> Thanks,
>> Weichen
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads, 
>> discussions,
>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev



-- 

Angel Pizarro
Director, Bioinformatics Facility
Institute for Translational Medicine and Therapeutics
University of Pennsylvania
806 BRB II/III
421 Curie Blvd.
Philadelphia, PA 19104-6160

P: 215-573-3736
F: 215-573-9004

[GUSDEV] ISF errors when using some files

[<fab...@de...>]

Hello gus-devers and users,

I have the InsertSequenceFeatures plugin loading genbank files in my GUS
installation without problems. Even so, there is some files I tried to lo=
ad
with the same plugin and two specific errors were generated. I'll try to
explain a little about them.

The first case is when I'm loading a genbank file which contains a /db_xr=
ef
parameter and the value is a database that doesn't exist in
Sres.ExternalDatabase. For instance, in tvivax.gb (attached) that paramet=
er is
/db_xref=3D"InterPro:IPR000173". In my case, Interpro isn't in my
Sres.ExternalDatabse table. When I run ISF with this file, the plugin wil=
l try
to load Interpro in Sres.ExternalDatabase and, I think, the
external_database_id
value generated to do the insertion isn't check if already exist. So, the
following error appears:

DBD::Pg::st execute failed: ERROR:  duplicate key violates unique constra=
int
"pk_externaldatabase" at
/usr/local/GUS/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 147, <GE=
N12>
line 58.

ERROR:

SQL ERROR!! involving

INSERT INTO SRes.ExternalDatabase (  group_write, other_read, group_read,=
 name,
user_read, row_user_id, external_database_id, modification_date, other_wr=
ite,
row_alg_invocation_id, row_project_id, row_group_id, user_write )
    VALUES   (  ?, ?, ?, ?, ?, ?, ?, now(), ?, ?, ?, ?, ? )
 Values: 1, 1, 1, InterPro, 1, 1, 3, 0, 92, 1, 1, 1

As I can see, external_database_id =3D 3. And in my Sres.ExternalDatabase=
 table
has a record with that pk value.

The second fault obtained was it:

ERROR:
In feature map XML file '../../config/genbank2gus.xml' <feature
name=3D"satellite"> does not havea <qualifier> for 'experiment', which is=
 found
in the input at
/usr/local/GUS/gus_home/lib/perl/GUS/Supported/BioperlFeatMapper.pm line =
88,
<GEN12> line 84.

this happened when I tried to load tvivax1.gb (attached). For some other =
files
plugin worked fine. Maybe you have already known about those plugin behav=
iors.
I'm just reporting my experimentations.=20

Best regards,

Fabr=EDcio.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [GUSDEV] question about coding in LoadSequenceFeatures.pm

[Steve F. <sfi...@pc...>]

yes.

-steve

Weichen Wu wrote:

> My question is about submit() method. In LoadSequenceFeatures.pm, 
> there is one line
>    $naSequence->submit();
> Does the submit method do the actual insertion into the 
> ExternalNASequence table?
>
> If I change variable $nasequence to $AAsequence, declare it as
> $aaSequence = GUS::Model::DoTS::ExternalAASequence( ), then set up 
> $aaSequence->sequenceID and taxonid and etc, finally run
> $aaSequence->submit();
> Will it insert a record to ExternalAASequence( )?
>
> Thanks,
> Weichen
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Re: [GUSDEV] mapping file

[Steve F. <sfi...@pc...>]

the only documentation is:
  ga GUS::Supported::Plugin::InsertSequenceFeatures --help

plus, use the default mapping file, and the default special case handler 
(GUS::Supported::SpecialCaseQualifierHandler)

ask questions as they come up.

steve

Weichen Wu wrote:

> Where can I find more document about mapping file or 
> reportFeatureQualifiers? I will create a mapping file.
>
> Thanks,
> Weichen
>
> ----- Original Message ----- From: "Steve Fischer" 
> <sfi...@pc...>
> To: "Weichen Wu" <we...@se...>
> Cc: <gus...@li...>
> Sent: Saturday, October 08, 2005 7:29 AM
> Subject: Re: [GUSDEV] mapping file
>
>
>> yes, the mapping file is required.  you can use the genbank2gus.xml 
>> file if your embl file uses features and qualifiers that conform to 
>> the genbank/embl/ddbj feature table (see 
>> http://www.ncbi.nlm.nih.gov/collab/FT/).
>> but, you must understand that input often does not conform, or, 
>> places data into qualifiers in the wrong way.
>>
>> in this case, you will need to provide your own mapping file.
>>
>> here is a snip from the documentation from the plugin (i just 
>> improved the doc in latest plugin version):
>>
>> --------
>> Another way to generate a template mapping file is by using the 
>> command reportFeatureQualifiers.  This command analyzes a set of 
>> input files, and reports the feature/qualifier structure found in 
>> them.  It can output the report in simple text form, or in XML that 
>> is a template for the mapping file.
>> --------
>>
>> steve
>>
>> Weichen Wu wrote:
>>
>>> Hi,
>>>
>>> To use InsertSequenceFeatures plugin, is the mapping file is 
>>> required? There is a genebank2gus.xml. Is there a mapping file for 
>>> EMBL format available?
>>>
>>> Thanks,
>>> Weichen
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by:
>>> Power Architecture Resource Center: Free content, downloads, 
>>> discussions,
>>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>>> _______________________________________________
>>> Gusdev-gusdev mailing list
>>> Gus...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>
>>
>>
>> CenterStudy 0000600 0077645 0077645 00100322707 10322742046 012406  0 
>> ustar   wewu 0000000 0000000 From cets Tue May  3 15:23:11 2005
>> Date: 03 May 2005 15:23:11 -0400
>> From: Ask CETS <ce...@ho...>
>> Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
>> Message-ID: <111...@ho...>
>> X-IMAP: 1101936235 0000000030
>> Status: RO
>>
>> Dear Email User,
>>
>> Hello!  My name is Paul Shaffer, and I'm a real person (not a computer
>> program).  I'm the "clerk" for the Eniac computer system here at SEAS.
>>
>> In order to keep track of your email, the computer needs to keep some
>> special directory information (things like which messages you've read).
>> This info is kept in an email message, which is kept in your 
>> mailbox.  In
>> fact, it is THIS VERY MESSAGE that keeps the directory info.
>>
>> Some other points you should know:
>>
>> + Don't delete this message - it will just come back if you do.
>>
>> + This message is created when you read mail using POP or IMAP, but
>>  you only see it when you read mail without POP or IMAP (e.g mutt or 
>> elm).
>>
>> + This message is like a bookmark.  POP or IMAP (the infrastructure that
>>  lets Netscape mail and Eudora work) creates it when you stop reading
>>  and looks for it when you start again.  It is stored here (rather than
>>  on your PC) so that you can use more than one machine and it will
>>  always be available.
>>
>> So, sit back, relax, and just IGNORE this message.  You need it.  You
>> can't get rid of it, so you might as well just get used to it.  If you
>> have any questions about what's going on, you can call 898-4707.
>>
>> Thank you for your understanding.
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

[GUSDEV] question about coding in LoadSequenceFeatures.pm

[Weichen W. <we...@se...>]

My question is about submit() method. In LoadSequenceFeatures.pm, there is 
one line
    $naSequence->submit();
Does the submit method do the actual insertion into the ExternalNASequence 
table?

If I change variable $nasequence to $AAsequence, declare it as
$aaSequence = GUS::Model::DoTS::ExternalAASequence( ), then set up 
$aaSequence->sequenceID and taxonid and etc, finally run
$aaSequence->submit();
Will it insert a record to ExternalAASequence( )?

Thanks,
Weichen

Re: [GUSDEV] mapping file

[Weichen W. <we...@se...>]

Where can I find more document about mapping file or 
reportFeatureQualifiers? I will create a mapping file.

Thanks,
Weichen

----- Original Message ----- 
From: "Steve Fischer" <sfi...@pc...>
To: "Weichen Wu" <we...@se...>
Cc: <gus...@li...>
Sent: Saturday, October 08, 2005 7:29 AM
Subject: Re: [GUSDEV] mapping file


> yes, the mapping file is required.  you can use the genbank2gus.xml file 
> if your embl file uses features and qualifiers that conform to the 
> genbank/embl/ddbj feature table (see 
> http://www.ncbi.nlm.nih.gov/collab/FT/).
> but, you must understand that input often does not conform, or, places 
> data into qualifiers in the wrong way.
>
> in this case, you will need to provide your own mapping file.
>
> here is a snip from the documentation from the plugin (i just improved the 
> doc in latest plugin version):
>
> --------
> Another way to generate a template mapping file is by using the command 
> reportFeatureQualifiers.  This command analyzes a set of input files, and 
> reports the feature/qualifier structure found in them.  It can output the 
> report in simple text form, or in XML that is a template for the mapping 
> file.
> --------
>
> steve
>
> Weichen Wu wrote:
>
>> Hi,
>>
>> To use InsertSequenceFeatures plugin, is the mapping file is required? 
>> There is a genebank2gus.xml. Is there a mapping file for EMBL format 
>> available?
>>
>> Thanks,
>> Weichen
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads, discussions,
>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
> 
> CenterStudy 
> 0000600 0077645 0077645 00100322707 10322742046 012406  0 
> ustar   wewu 
> 0000000 0000000 
> From cets Tue May  3 15:23:11 2005
> Date: 03 May 2005 15:23:11 -0400
> From: Ask CETS <ce...@ho...>
> Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
> Message-ID: <111...@ho...>
> X-IMAP: 1101936235 0000000030
> Status: RO
>
> Dear Email User,
>
> Hello!  My name is Paul Shaffer, and I'm a real person (not a computer
> program).  I'm the "clerk" for the Eniac computer system here at SEAS.
>
> In order to keep track of your email, the computer needs to keep some
> special directory information (things like which messages you've read).
> This info is kept in an email message, which is kept in your mailbox.  In
> fact, it is THIS VERY MESSAGE that keeps the directory info.
>
> Some other points you should know:
>
> + Don't delete this message - it will just come back if you do.
>
> + This message is created when you read mail using POP or IMAP, but
>  you only see it when you read mail without POP or IMAP (e.g mutt or elm).
>
> + This message is like a bookmark.  POP or IMAP (the infrastructure that
>  lets Netscape mail and Eudora work) creates it when you stop reading
>  and looks for it when you start again.  It is stored here (rather than
>  on your PC) so that you can use more than one machine and it will
>  always be available.
>
> So, sit back, relax, and just IGNORE this message.  You need it.  You
> can't get rid of it, so you might as well just get used to it.  If you
> have any questions about what's going on, you can call 898-4707.
>
> Thank you for your understanding.
> 

[GUSDEV] GUS Uninstaller

[Michael S. <msa...@pc...>]

All,

I've committed a small utility to the GUS trunk that will perform a
de-installation of GUS from a database (Oracle or Postgres).  The utility
does not affect any files in the file system (i.e. $GUS_HOME or
$PROJECT_HOME).

THIS WILL DELETE DATA!

The script drops all of the GUS schemas/users (i.e. DoTS, Sres, and so on,
including the corresponding version schemas/users).  All tables in these
schemas will be remove.

To get it, do an svn checkout or update of the GusAppFramework project.  You
must then build by doing a build GUS install -append.

Finally, run:  

$ dbaDeinstallGus

It will use the properties in your $GUS_HOME/config/gus.config file, and ask
for confirmation.  Please be careful to double check the database connection
string.  You must have dba privileges to use this tool.

Please let me know if you have any questions-

--Mike

Re: [GUSDEV] Gus Build problems

[Michael S. <msa...@pc...>]

There's not an easy way to do this at the moment... There should be a
deinstall script in the trunk by EOD

Here's what I do (in Oracle):

drop user core cascade;
drop user prot cascade;
drop user study cascade;
drop user dots cascade;
drop user tess cascade;
drop user rad cascade;
drop user sres cascade;

drop user corever cascade;
drop user protver cascade;
drop user studyver cascade;
drop user dotsver cascade;
drop user tessver cascade;
drop user radver cascade;
drop user sresver cascade;



--Mike




On 10/19/05 1:55 PM, "Juan Carlos Perin" <bi...@ge...> wrote:

> Mike,
> 
> This is a clean install, on a brand new instance of oracle.  If anything is
> in there from GUS, it'd be from a previous attempt to build.  In any case, I
> assume a cleanout would do the trick.  Is there an easy way to do that?
> 
> THANKS
> 
> 
> On 10/19/05 1:09 PM, "Michael Saffitz" <msa...@pc...> wrote:
> 
>> 
>> Hi Juan,
>> 
>> It looks like there's an existing GUS instance.  Make sure to completely
>> clean out the database (by dropping all GUS users-- Core, DoTS, SResVer,
>> DoTSVer, and so on) an then reinstalling.  (Note:  You will loose any data
>> in these schemas when you drop them!).
>> 
>> --Mike
>> 
>> 
>> On 10/19/05 11:08 AM, "Juan Carlos Perin" <bi...@ge...> wrote:
>> 
>>> Hello, I'm very new to oracle and have had a few issues building GUS.  I'm
>>> running Oracle 10g on a Poweredge server running Redhat AS3.  I've created a
>>> tablespace called GUS to build into, and finally got past some 'connect'
>>> errors.  I get the following error when running build:
>>> 
>>> BUILD FAILED
>>> /home/oracle/GUS/project_home/install/build.xml:28: The following error
>>> occurred while executing this line:
>>> /home/oracle/GUS/project_home/GUS/build.xml:92: java.io.IOException: Error
>>> executing SQL: '
>>> CREATE USER SResVer IDENTIFIED BY temppass PASSWORD EXPIRE ACCOUNT LOCK
>>> QUOTA UNLIMITED ON USERS DEFAULT TABLESPACE USERS' Error: ORA-01920: user
>>> name 'SRESVER' conflicts with another user or role name
>>> 
>>> The last time I tried, it gave me this error when trying to create User
>>> PROT.  I'm not sure why it got to different points, nothing changed.  I am
>>> using an oracle account I created that I gave all privileges to.  I assume
>>> maybe I'm getting this error because of multiple attempts to build, but I'm
>>> not sure how to clear things off to start again, if that's the case.  Any
>>> pointers would be great.  I'm happy to read documentation, just wish I knew
>>> where to start.  Thanks all!
>>> 
>>> Juan Perin
>>> 
>>> 
>>> 
>>> 
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by:
>>> Power Architecture Resource Center: Free content, downloads, discussions,
>>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>>> _______________________________________________
>>> Gusdev-gusdev mailing list
>>> Gus...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>> 
>> 
>> 
> 

Re: [GUSDEV] Gus Build problems

[Michael S. <msa...@pc...>]

Hi Juan,

It looks like there's an existing GUS instance.  Make sure to completely
clean out the database (by dropping all GUS users-- Core, DoTS, SResVer,
DoTSVer, and so on) an then reinstalling.  (Note:  You will loose any data
in these schemas when you drop them!).

--Mike


On 10/19/05 11:08 AM, "Juan Carlos Perin" <bi...@ge...> wrote:

> Hello, I'm very new to oracle and have had a few issues building GUS.  I'm
> running Oracle 10g on a Poweredge server running Redhat AS3.  I've created a
> tablespace called GUS to build into, and finally got past some 'connect'
> errors.  I get the following error when running build:
> 
> BUILD FAILED
> /home/oracle/GUS/project_home/install/build.xml:28: The following error
> occurred while executing this line:
> /home/oracle/GUS/project_home/GUS/build.xml:92: java.io.IOException: Error
> executing SQL: '
> CREATE USER SResVer IDENTIFIED BY temppass PASSWORD EXPIRE ACCOUNT LOCK
> QUOTA UNLIMITED ON USERS DEFAULT TABLESPACE USERS' Error: ORA-01920: user
> name 'SRESVER' conflicts with another user or role name
> 
> The last time I tried, it gave me this error when trying to create User
> PROT.  I'm not sure why it got to different points, nothing changed.  I am
> using an oracle account I created that I gave all privileges to.  I assume
> maybe I'm getting this error because of multiple attempts to build, but I'm
> not sure how to clear things off to start again, if that's the case.  Any
> pointers would be great.  I'm happy to read documentation, just wish I knew
> where to start.  Thanks all!
> 
> Juan Perin
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

[GUSDEV] Gus Build problems

[Juan C. P. <bi...@ge...>]

Hello, I'm very new to oracle and have had a few issues building GUS.  I'm
running Oracle 10g on a Poweredge server running Redhat AS3.  I've created a
tablespace called GUS to build into, and finally got past some 'connect'
errors.  I get the following error when running build:

BUILD FAILED
/home/oracle/GUS/project_home/install/build.xml:28: The following error
occurred while executing this line:
/home/oracle/GUS/project_home/GUS/build.xml:92: java.io.IOException: Error
executing SQL: '
CREATE USER SResVer IDENTIFIED BY temppass PASSWORD EXPIRE ACCOUNT LOCK
QUOTA UNLIMITED ON USERS DEFAULT TABLESPACE USERS' Error: ORA-01920: user
name 'SRESVER' conflicts with another user or role name

The last time I tried, it gave me this error when trying to create User
PROT.  I'm not sure why it got to different points, nothing changed.  I am
using an oracle account I created that I gave all privileges to.  I assume
maybe I'm getting this error because of multiple attempts to build, but I'm
not sure how to clear things off to start again, if that's the case.  Any
pointers would be great.  I'm happy to read documentation, just wish I knew
where to start.  Thanks all!

Juan Perin