incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: Multi product enhancements
Date Wed, 14 Nov 2012 08:38:25 GMT
On 11/13/12, Jure Zitnik <jure@digiverse.si> wrote:
> On 11/7/12 9:58 PM, Gary Martin wrote:
>> On 7 November 2012 09:29, Branko Čibej <brane@wandisco.com> wrote:
>>> On 07.11.2012 08:42, Jure Zitnik wrote:
>
[...]
>
> I did a bit of code digging to get an idea how the product ticket
> namespace could be implemented and I came up with a problem described
> below ...
>
> In my opinion the most obvious way to keep the product ticket namespace
> would be to introduce a new database table that would link the product
> to the ticket by adding additional info,

If you need a new product-specific ticket number sequence (which I
don't think is really needed , at least for the moment) maybe that's
ok *IF* other mechanism like custom ticket fields is not enough.

> such as ticket sequence in that
> namespace.

btw , what's the decision on having consecutive ticket sequence
per-product ? Is it a design goal ? That will only make things harder
at the beginning while we try to sort out more important puzzles . Can
we make it clear whether consecutive ticket sequence per-product will
be included or not ?

fwiw ... I'm -1 about adding it soon ... maybe later

>
> But as we want to perform the database inserts prior to sending out
> email notifications (let's say we want to include newly generated URLs
> from the product ticket namespace in the notification emails) we can't
> really simply call the original/trac methods. So, to accomplish this
> (single transaction for both inserts, product ticket namespace URLs in
> notifications), we would need to literally copy parts of the trac code
> to the overriden methods and add/modify the code to handle product
> ticket namespace and notifications ...
>

The solution for adjustment of product resource URLs should happen
transparently . That's what «product environments» [1]_ are for . I'll
explain how they'd work soon once I continue writing BEP 3 . Feel free
to drop some ideas in there too ;)

[...]
> Patching trac would
> possibly solve this but if we want to keep the plugin functionality
> separate from trac that's really not the proper way of doing things.

Please let's try to modify (copy , duplicate ...) code rarely , and
only if there's a very good reason to do so . Changing things in there
may break many other parts of the system and external plugins .

> Using the trac code copy in overridden methods is also suboptimal. I
> noticed though that the bloodhound theme (quick ticket create) sort of
> uses this second approach.
>

Kind of ... but create_ticket has been copied from XmlRpcPlugin , so
it's a well-known , reliable (and tested ;) implementation .

> I'm bringing this up partly because I have a strong suspicion that we'll
> come across the same issues if/when we start thinking of implementing
> per product wiki, components, milestones, versions, etc.
>

Yes . So the solution should not be to start patching Trac all over
and (it does not stop there) merging subsequent changes with time .

.. [1] Some ideas on Multiproduct architecture
        (https://issues.apache.org/bloodhound/attachment/wiki/Proposals/BEP-0003/Multiproduct.png)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Mime
View raw message