incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jure Zitnik <j...@digiverse.si>
Subject Re: [Apache Bloodhound] #355: Run Trac test suite against product environments - after #115 #288
Date Fri, 22 Feb 2013 11:03:57 GMT
On 2/22/13 9:47 AM, Apache Bloodhound wrote:
> #355: Run Trac test suite against product environments - after #115 #288
> ---------------------------+------------------------------------
>    Reporter:  olemis        |      Owner:  olemis
>        Type:  task          |     Status:  accepted
>    Priority:  major         |  Milestone:
>   Component:  multiproduct  |    Version:
> Resolution:                |   Keywords:  environment testing QA
> ---------------------------+------------------------------------
>
> Comment (by olemis):
>
>   [...]
>
>   @jure : the only thing I'm missing to finish with wiki syntax test cases
>   is the translation of `attachment` table . Because of that reason TCs for
>   `attachment:` TracLinks still will fail . That's missing and somehow we
>   overlooked this once upon a time . That also means that we should review
>   once again the list of tables that have to be translated and spend some
>   time writing TCs for environment isolation hoping to detect any similar
>   situation ... needless to say the same holds for plugins .
>

Currently ticket, enum, component, milestone, version, permission and 
wiki tables are translated.

I agree that the 'attachment' table should also be added to the list. 
The 'system' table will be added as that's required by non-product aware 
component upgrade process. I also noticed that 'ticket_change' and 
'ticket_custom' tables are currently exluded from the translator and 
should be added too.

jftr, the following tables (not accounting for the aforementioned 
changes) are explicitly exluded from translation: system, auth_cookie, 
session, session_attribute, cache, attachment, repository, revision, 
node_change, ticket_change, ticket_custom, report, bloodhound_product, 
bloodhound_productresourcemap, bloodhound_productconfig.

All other tables encountered are considered custom (plugin created) and 
are translated accordingly (by pre-pending product prefix to table names).

A related question, is multiproduct.model.ProductResourceMap actually 
used anywhere at the moment? Looking at the code it doesn't seem to be, 
it only gets created with the schema and queried when removing a product...

Cheers,
Jure


Mime
View raw message