You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Jure Zitnik <ju...@digiverse.si> on 2013/02/22 12:03:57 UTC
Re: [Apache Bloodhound] #355: Run Trac test suite against product
environments - after #115 #288
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
Re: [Apache Bloodhound] #355: Run Trac test suite against product
environments - after #115 #288
Posted by Jure Zitnik <ju...@digiverse.si>.
On 2/22/13 4:26 PM, Olemis Lang wrote:
> On 2/22/13, Jure Zitnik <ju...@digiverse.si> wrote:
>> On 2/22/13 9:47 AM, Apache Bloodhound wrote:
>>> #355: Run Trac test suite against product environments - after #115 #288
> [...]
>> 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.
> +1
>
>> 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 ?
>
The exclude list does (did) not include the changes, so it reflects
state before the changes mentioned.
>> 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
I think that 'ticket_change' and 'ticket_custom' should also be included
in the translator, just to keep things consistent and to prevent non
multi-product aware components running in product scope from accessing
data in other product scopes.
>> 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 ;)
+1
>> 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 .
>
I will add those to the translate list for now as explained above.
>> report,
> should be translated
>
+1
To summarize, 'attachment', 'ticket_change', 'ticket_custom' and
'report' tables will be added to the translator list.
What we'll do with the 'system' table depends on discussions in other
thread (database upgrade etc.).
Cheers,
Jure
Re: [Apache Bloodhound] #355: Run Trac test suite against product
environments - after #115 #288
Posted by Olemis Lang <ol...@gmail.com>.
On 2/22/13, Jure Zitnik <ju...@digiverse.si> 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.
+1
> 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 .
;)
--
Regards,
Olemis.