bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [Apache Bloodhound] #355: Run Trac test suite against product environments - after #115 #288
Date Fri, 22 Feb 2013 15:26:43 GMT
On 2/22/13, Jure Zitnik <> wrote:
> On 2/22/13 9:47 AM, Apache Bloodhound wrote:
>> #355: Run Trac test suite against product environments - after #115 #288
>> 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.

am I missing something or u listed system in excluded tables list below ?

> I also noticed that 'ticket_change' and
> 'ticket_custom' tables are currently exluded from the translator and
> should be added too.

Based on our previous discussion they should not given the fact that
ticket ID is still global . In this case what is missing are the DB
tables implementing product-specific ticket seq numbers

> jftr, the following tables (not accounting for the aforementioned
> changes)

wrapping up ...

> are explicitly exluded from translation: system, auth_cookie,
> session, session_attribute, cache,

all this is global stuff

> attachment,

should be translated

> repository, revision,
> node_change,

these are for the VCS . IMO repositories should be global and have
«soft links» to products , thus allowing for reusing them in different
product contexts . We might prefer the notion of per-product forks
instead . So this is open for debate (in a separate thread / ticket
... please ;)

> ticket_change, ticket_custom,

if ticket ID will be global then these are global as well , and
additional ticket seq DB tables will be added ... otherwise they
should be translated .

> report,

should be translated

> bloodhound_product,
> bloodhound_productresourcemap, bloodhound_productconfig.

obviously global .

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

good to know ... I guess I'll take a look into this and hack a little
in the next few days .



View raw message