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/20 12:37:19 UTC
[BEP-0003] Database upgrade to multi-product (Was: Re: [Apache Bloodhound]
#406: Database upgrade to multiproduct)
I don't think this was discussed on the mailing list yet.
The question is how do we upgrade existing database(s) (pre
multi-product) to multi-product enabled one and how to migrate existing
data to a new schema.
Upgrade that's been implemented as part of the #288 currently does the
following:
1. adds 'default' product
This is the product to which all tickets that don't have product set are
migrated. As there won't be any global tickets, each ticket needs to be
in a product, so this is where all tickets w/o product set will end up
after the upgrade. The prefix, name and description are currently set to
'default', 'Default' and 'Default product' respectively. Open question
remains what happens if there's a product with the same name already
defined in the database. Any suggestions?
2. migrates tickets w/o the product set to the 'default' product
3. copies data from enum, component, milestone, version, permission and
wiki (all 'product enabled' tables) to temporary tables
4. drops old tables (listed in step 3) - to be replaced by product
enabled schema in step 5
5. creates new, 'product enabled' tables (list from step 3) with added
'product' column
6. populates product enabled tables created in step 5 with data from
step 3 for each defined product (including default one added in step 1)
This in effect multiplies product enabled resources for each defined
product. This is required to keep the consistency across different
products as tickets might reference any resource from previously global
tables.
There is one exception though, for permission table the data from the
temporary table is also populated into the global scope (empty product
prefix).
7. drops old (temporary) tables
After the process the database ends up with:
- upgraded schema for enum, component, milestone, version, permission
and wiki tables
- new 'default' product
- tickets that were not assigned to the product prior to database
upgrade are migrated to the new default product
- resources from previously global scope are multiplied for each defined
product
Any comments/suggestions on this?
Cheers,
Jure
On 2/20/13 11:45 AM, Apache Bloodhound wrote:
> #406: Database upgrade to multiproduct
> -----------------------------------+------------------
> Reporter: jure | Owner: jure
> Type: defect | Status: new
> Priority: major | Milestone:
> Component: multiproduct | Version:
> Keywords: bep-0003 multiproduct |
> -----------------------------------+------------------
> Implement database upgrade from non multiproduct enabled database to
> multiproduct enabled one.
>
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Joachim Dreimann <jo...@wandisco.com>.
You could argue that if you have global wikis, you may want global tickets
to allow for "Update global documentation"-type tickets.
I'm skeptical about both global tickets and global wikis from a UX
perspective as they represent a 'miscellaneous' category, which we should
discourage because they often end up like the attics that no one ever cares
to clean out.
- Joe
On 22 February 2013 10:41, Jure Zitnik <ju...@digiverse.si> wrote:
> On 2/22/13 3:03 AM, Branko Čibej wrote:
>
>> On 21.02.2013 18:05, Olemis Lang wrote:
>>
>>> On 2/21/13, Jure Zitnik <ju...@digiverse.si> wrote:
>>>
>>>> On 2/20/13 5:21 PM, Olemis Lang wrote:
>>>>
>>>>> On 2/20/13, Andrej Golcov <an...@digiverse.si> wrote:
>>>>>
>>>> [...]
>>>
>>>> My suggestion is to keep things simple here: if there is already
>>>>>> product named "Default', let's assign global tickets to this product.
>>>>>> There should be reason why this product was called "Default" :)
>>>>>>
>>>>>> -1 ... IMO we the prefix for the global environment should be an
>>>>> empty
>>>>> string (i.e. '') or NULL (/me slightly in favor of the former) . That
>>>>> will allow us to reserve special behavior for that prefix value (if
>>>>> needed) and will not clash with any other valid product prefix since
>>>>> it's a required field in create product web form (... admin command ,
>>>>> ...)
>>>>>
>>>>> Just to clarify, the prefix of the 'global environment' is an empty
>>>> string (''). This will, at the moment, only be used for permissions.
>>>>
>>>> Yes , understood .
>>> ;)
>>>
>>> The 'default' prefix (or 'def') is used for a product to which all the
>>>> tickets that don't have product assigned are migrated to (during the
>>>> database upgrade process). The product itself is automatically added
>>>> during the upgrade/migration process.
>>>>
>>>> That's kind of what I was meaning in my reply .
>>>
>>> 1. Consider ticket without product before migration to be
>>> tickets filed against the global environment .
>>> 2. Use gobal env just like any other product env with
>>> prefix = '' , not just permissions
>>> 3. No need to create 'default' product while on upgrade
>>>
>>> PS: In the migration process we should also replicate (i.e. in DB) or
>>> inherit product configs from a single file . I advocate for the later
>>> .
>>>
>> I have to say that for once I completely agree with Olemis. NULL table
>> column, and empty UI prefix equals "it all looks exactly like it used to
>> before the migration" and it also can't collide with any existing
>> product names or prefixes.
>>
>> Furthermore, doing it this way, if a user installs Bloodhound but
>> doesn't want to bother with product namespaces, everything will Just Work.
>>
>> I agree with the 'Just Work' part, I don't agree with tickets in global
> scope.
>
> My understanding was, based on the mailing list discussions, that we don't
> want tickets in global scope. That is why current implementation creates
> the 'default' product and migrates the tickets. I think that the 'Just
> Work' part is more of the UI/UX issue. I think that each ticket should be
> linked to a product, it's up to the UI to make it easy for the user to use
> environments with only one product (default one). I find tickets in global
> scope confusing as it's not exactly clear what they relate to.
>
> I would advocate global wikis for example, as it makes more sense.
>
> Cheers,
> Jure
>
>
>
--
Joe Dreimann
UX Designer | WANdisco <http://www.wandisco.com/>
*
*
*Transform your software development department. Register for a free SVN
HealthCheck <http://go.wandisco.com/HealthCheck-Sig.html> *
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Jose Angel Franco Navarro <ja...@gmail.com>.
Hello,
2013/2/22, Olemis Lang <ol...@gmail.com>:
> On 2/22/13, Branko Čibej <br...@wandisco.com> wrote:
>> On 22.02.2013 11:41, Jure Zitnik wrote:
>>> On 2/22/13 3:03 AM, Branko Čibej wrote:
> [...]
>>>> I have to say that for once I completely agree with Olemis. NULL table
>>>> column, and empty UI prefix equals "it all looks exactly like it used
>>>> to
>>>> before the migration" and it also can't collide with any existing
>>>> product names or prefixes.
>>>>
>>>> Furthermore, doing it this way, if a user installs Bloodhound but
>>>> doesn't want to bother with product namespaces, everything will Just
>>>> Work.
>>>>
>>> I agree with the 'Just Work' part, I don't agree with tickets in
>>> global scope.
>>>
>>> My understanding was, based on the mailing list discussions, that we
>>> don't want tickets in global scope. That is why current implementation
>>> creates the 'default' product and migrates the tickets. I think that
>>> the 'Just Work' part is more of the UI/UX issue. I think that each
>>> ticket should be linked to a product, it's up to the UI to make it
>>> easy for the user to use environments with only one product (default
>>> one). I find tickets in global scope confusing as it's not exactly
>>> clear what they relate to.
>>>
>>> I would advocate global wikis for example, as it makes more sense.
>>
>> It's not global scope, it's default product scope which happens to have
>> no name and no prefix and no value in the related database column.
>>
> [...]
>>
>> Under the hood, this can be a completely different thing than the global
>> scope.
>>
>
> jftr , I confirm this is what I had in mind since the beginning .
>
>
>>
>> P.S.: By the way, do we test upgrades from Trac to BH? If not, why not?
>> :)
>>
>
> We should . That's another argument against performing MP upgrade in
> EnvironmentStub.__init__ method (i.e. at the beginning of one such
> test the env would be upgraded already o.O ) . In general , testing
> upgrades will be easier after committing BEP-5 and refactoring
> MultiproductSystem procedure accordingly . AFAICR franco included some
> test cases for upgrades so it seems it all (or good part of it ;) will
> come in a single package .
>
> @franco : coluld you please confirm ?
Yes, BEP-5 would allow to have upgrades encapsulated per plugin
version, thus providing a better testability of specific version
upgrades as well as full from scratch upgrade scenarios.
Test cases might be written to verify specific upgrade needs as they
have been written for BEP-5 itself.
> --
> Regards,
>
> Olemis.
Best regards,
Franco.
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Olemis Lang <ol...@gmail.com>.
On 2/27/13, Branko Čibej <br...@wandisco.com> wrote:
> On 27.02.2013 13:01, Olemis Lang wrote:
>> On 2/27/13, Jure Zitnik <ju...@digiverse.si> wrote:
>>> On 2/22/13 4:34 PM, Olemis Lang wrote:
>>>> On 2/22/13, Branko Čibej <br...@wandisco.com> wrote:
>>>> [...]
>>>>> P.S.: By the way, do we test upgrades from Trac to BH? If not, why
>>>>> not?
>>>>> :)
>>>>>
>>>> We should .
>>> +1
>>>
>>> It'd be really helpful if we could get hold of a real trac database to
>>> perform tests on. Anyone got access to a database snapshot that we could
>>> use for testing?
>>>
>> Ideally I'd advocate for writing unit and/or functional tests for MP
>> upgrades .
>
> Yes, but you'll never invent tests that reproduce real-world cases
> without looking at real-world cases in the first place.
>
That's what I'd call functional tests . Trac test suite includes some
of them in which a whole environment is created once then shared among
TCs in a test fixture and invoke the whole Trac machinery using twill
to trigger web processing in-process . They'd be close to what u'd get
with manual testing ... with the added benefit of automation e.g.
track regressions . They'd be a sort of «robot» using Bloodhound in
well-known , predefined manner and checking for expected behavior
based on system output.
Having real env data at the beginning is addressed by test fixtures .
BTW , this kind of automation is not an urgent matter , so think of my
comments to be a suggestion to adopt in the long-run
PS: Testing approaches will never be perfect ... but may be quite
similar to reality
--
Regards,
Olemis.
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Branko Čibej <br...@wandisco.com>.
On 27.02.2013 13:01, Olemis Lang wrote:
> On 2/27/13, Jure Zitnik <ju...@digiverse.si> wrote:
>> On 2/22/13 4:34 PM, Olemis Lang wrote:
>>> On 2/22/13, Branko Čibej <br...@wandisco.com> wrote:
>>> [...]
>>>> P.S.: By the way, do we test upgrades from Trac to BH? If not, why not?
>>>> :)
>>>>
>>> We should .
>> +1
>>
>> It'd be really helpful if we could get hold of a real trac database to
>> perform tests on. Anyone got access to a database snapshot that we could
>> use for testing?
>>
> Ideally I'd advocate for writing unit and/or functional tests for MP upgrades .
Yes, but you'll never invent tests that reproduce real-world cases
without looking at real-world cases in the first place.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Olemis Lang <ol...@gmail.com>.
On 2/27/13, Jure Zitnik <ju...@digiverse.si> wrote:
> On 2/22/13 4:34 PM, Olemis Lang wrote:
>> On 2/22/13, Branko Čibej <br...@wandisco.com> wrote:
>> [...]
>>> P.S.: By the way, do we test upgrades from Trac to BH? If not, why not?
>>> :)
>>>
>> We should .
> +1
>
> It'd be really helpful if we could get hold of a real trac database to
> perform tests on. Anyone got access to a database snapshot that we could
> use for testing?
>
Ideally I'd advocate for writing unit and/or functional tests for MP upgrades .
--
Regards,
Olemis.
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Olemis Lang <ol...@gmail.com>.
Hi Gary !
:)
I'm posting inline replies based on what I considered in the patches
I'm developing my side for #390
On 2/27/13, Gary Martin <ga...@wandisco.com> wrote:
> On 26/02/13 09:07, Andrej Golcov wrote:
[...]
>>
>> And wiki links will probably look like (as far as I understand
>> previous discussion on this subject):
>> #<delimiter>1 - I think we cannot use "#1" since it should be reserved
>> for relative within product links to avoid migration problems
>> #prod1<delimiter>2
>> #prod2<delimiter>3
>>
>> IMHO, it is user confusing.
>>
>
> I don't think that #prod1<delimiter>123 works for me.
+1
> Would we also
> expect to see milestone:prod1<delimiter>milestone1 as appropriate?
definitely no
[..]
> I am expecting #123 to resolve to the appropriate ticket number within
> each product which, as already pointed out, helps with migration
> problems.
+1
> I don't see why this would be a particular problem for the
> global env. #123 works equally well there when you are within global scope.
>
yes
> For me, the only issue is how tickets within a product will refer to
> tickets in the global scope. There are actually a fair number of
> potential solutions including:
>
> 1. Reserve a keyword to represent the global env (e.g. def, default,
> global, null or whatever)
This is it ! I'm considering global: prefix and it will work in a
similar way to Intertrac prefixes e.g. global:ticket:333 , global:#333
, ...
> 2. Allow for a missing product within product syntax to work (e.g.
> <delimiter>123,
-1
> <delimiter>#123,
-1
> product:#123
IMO global: is less ambiguous . Besides this form will over-complicate
for no reason the solution . At present this will generate an URL of
the form /products/%23123 which would be equivalent to a link to
product having prefix '#123' . Whether we shall allow using such
prefixes or not is another discussion ; and if not they will always be
rendered as 'missing product' links thus hinting that something went
wrong in first place .
> and product::ticket:123)
This one *might* work as it's less ambiguous and should be matched by
the TracLinks resolver . If you see some value in using these ,
please let me know so that I can add it sooner than later .
> 3. Use empty quotes to miss out the product prefix (e.g.
> ''<delimiter>123,
-1
> ''<delimiter>#123,
> product:'':#123 and
> product:'':ticket:123)
>
AFAICS these might not work even if it seems they should. I say so
based on similar test cases I just wrote , and it seems to me that the
TracLinks resolver will leave everything after ' chars outside of link
definition (since it is in the middle ;) . Anyway I'll add a test case
to confirm this , because the ones mention employ " chars , so they
might be treated slightly different.
> We could also consider only allowing the longhand forms of 2 or 3 above.
> I find myself leaning towards a reserved product name
+1
Summarizing , we both are in sync Gary . Further comments are welcome
, of course . I'll consider all these forms to write test cases and
see where them all will take us .
/me working on this ... should be ready soon .
--
Regards,
Olemis.
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Olemis Lang <ol...@gmail.com>.
On 2/28/13, Andrej Golcov <an...@digiverse.si> wrote:
>> For me, the only issue is how tickets within a product will refer to
>> tickets
>> in the global scope. There are actually a fair number of potential
>> solutions
>> including:
>>
>> 1. Reserve a keyword to represent the global env (e.g. def, default,
>> global, null or whatever)
> +1 to have global/default/whatever keyword as it looks less ambiguous.
:)
> In this case it worth to have also url access with the same keyword e.g.
-1
> http://host/env/products/global/ticket/1 for global env
The TracLinks expression for this will be product:global:ticket:1 .
The one for global env will be global:ticket:1 and will be expanded to
http://host/env/ticket/1 . That's exactly what disambiguation is all
about
;)
> http://host/env/products/prod1/ticket/2 for prod1 env
>
jftr product:prod1:ticket:2
> In this case, there is one thing to discuss on this subject: what
> exactly global env resources have in db after migration: NULL or
> global/default/whatever string.
> Personally, +1 to have string instead of NULL
>
IMO it should be '' i.e. empty string , otherwise NULL . IMO we better
use '' because SQL checks for NULL values will required product IS
NULL predicate as opposite to WHERE product = '' . Choosing the second
will allow us to provide an uniform treatment to both global and
product data at SQL translation time .
--
Regards,
Olemis.
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Gary Martin <ga...@wandisco.com>.
On 28/02/13 10:54, Andrej Golcov wrote:
>> For me, the only issue is how tickets within a product will refer to tickets
>> in the global scope. There are actually a fair number of potential solutions
>> including:
>>
>> 1. Reserve a keyword to represent the global env (e.g. def, default,
>> global, null or whatever)
> +1 to have global/default/whatever keyword as it looks less ambiguous.
> In this case it worth to have also url access with the same keyword e.g.
> http://host/env/products/global/ticket/1 for global env
> http://host/env/products/prod1/ticket/2 for prod1 env
>
> In this case, there is one thing to discuss on this subject: what
> exactly global env resources have in db after migration: NULL or
> global/default/whatever string.
> Personally, +1 to have string instead of NULL
>
> Cheers, Andrej
I am worried that I might have taken this full circle. I would stick
with NULL as the value in the database, particularly if we consider that
there may be existing products with whatever keyword we choose. It would
be nice to be able to ignore clashes but it might be a bit
irresponsible. We could consider any legacy clashing products as being
allowed to occupy that namespace and just force the use of another means
to disambiguate.
I quite like the suggestion from Olemis of allowing something like
global:#123 (or whatever word we choose). So, I appear to be advocating
one or both of
<globalkeyword>:#123
product::#123
referring to http://host/env/ticket/123 to be the ultimate form(s) of
disambiguation.
Cheers,
Gary
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Andrej Golcov <an...@digiverse.si>.
> For me, the only issue is how tickets within a product will refer to tickets
> in the global scope. There are actually a fair number of potential solutions
> including:
>
> 1. Reserve a keyword to represent the global env (e.g. def, default,
> global, null or whatever)
+1 to have global/default/whatever keyword as it looks less ambiguous.
In this case it worth to have also url access with the same keyword e.g.
http://host/env/products/global/ticket/1 for global env
http://host/env/products/prod1/ticket/2 for prod1 env
In this case, there is one thing to discuss on this subject: what
exactly global env resources have in db after migration: NULL or
global/default/whatever string.
Personally, +1 to have string instead of NULL
Cheers, Andrej
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Gary Martin <ga...@wandisco.com>.
On 26/02/13 09:07, Andrej Golcov wrote:
>> Once again this is not accurate . Product URL mappings will be
>>
>> http://host/env/products/<prefix>/ticket/1
>>
>> ... notice 'products' path prefix
>>
>> URLs for global env will be just like they are now
>>
>> http://host/env/ticket/1
> That means, BH user will have tickets available with the following urls:
> http://host/env/ticket/1 - for NULL prefix
> http://host/env/products/prod1/ticket/2
> http://host/env/products/prod2/ticket/3
>
> And wiki links will probably look like (as far as I understand
> previous discussion on this subject):
> #<delimiter>1 - I think we cannot use "#1" since it should be reserved
> for relative within product links to avoid migration problems
> #prod1<delimiter>2
> #prod2<delimiter>3
>
> IMHO, it is user confusing.
>
> Cheers, Andrej
I don't think that #prod1<delimiter>123 works for me. Would we also
expect to see milestone:prod1<delimiter>milestone1 as appropriate? I
would encourage prod1<delimiter>123, prod1<delimiter>#123 and
prod1<delimiter>milestone:milestone1 instead though that is
I am expecting #123 to resolve to the appropriate ticket number within
each product which, as already pointed out, helps with migration
problems. I don't see why this would be a particular problem for the
global env. #123 works equally well there when you are within global scope.
For me, the only issue is how tickets within a product will refer to
tickets in the global scope. There are actually a fair number of
potential solutions including:
1. Reserve a keyword to represent the global env (e.g. def, default,
global, null or whatever)
2. Allow for a missing product within product syntax to work (e.g.
<delimiter>123, <delimiter>#123, product:#123 and product::ticket:123)
3. Use empty quotes to miss out the product prefix (e.g.
''<delimiter>123, ''<delimiter>#123, product:'':#123 and
product:'':ticket:123)
We could also consider only allowing the longhand forms of 2 or 3 above.
I find myself leaning towards a reserved product name although I realise
that such an approach could clash with existing product prefixes.
Cheers,
Gary
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Andrej Golcov <an...@digiverse.si>.
> Once again this is not accurate . Product URL mappings will be
>
> http://host/env/products/<prefix>/ticket/1
>
> ... notice 'products' path prefix
>
> URLs for global env will be just like they are now
>
> http://host/env/ticket/1
That means, BH user will have tickets available with the following urls:
http://host/env/ticket/1 - for NULL prefix
http://host/env/products/prod1/ticket/2
http://host/env/products/prod2/ticket/3
And wiki links will probably look like (as far as I understand
previous discussion on this subject):
#<delimiter>1 - I think we cannot use "#1" since it should be reserved
for relative within product links to avoid migration problems
#prod1<delimiter>2
#prod2<delimiter>3
IMHO, it is user confusing.
Cheers, Andrej
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Olemis Lang <ol...@gmail.com>.
On 2/25/13, Andrej Golcov <an...@digiverse.si> wrote:
>>>> My understanding was, based on the mailing list discussions, that we
>>>> don't want tickets in global scope. That is why current implementation
>>>> creates the 'default' product and migrates the tickets. I think that
>>>> the 'Just Work' part is more of the UI/UX issue. I think that each
>>>> ticket should be linked to a product, it's up to the UI to make it
>>>> easy for the user to use environments with only one product (default
>>>> one). I find tickets in global scope confusing as it's not exactly
>>>> clear what they relate to.
>>>>
>>>> I would advocate global wikis for example, as it makes more sense.
>>>
>>> It's not global scope, it's default product scope which happens to have
>>> no name and no prefix and no value in the related database column.
>
> Let's look at this issue from UI point of view. AFAIR, we want to have
> consistent URLs and wiki links with product prefix for all products
> including default product
> e.g.http://host/env/default_product_name_here/ticket/1 and not
> http://host/env/ticket/1 when product prefix is None
Once again this is not accurate . Product URL mappings will be
http://host/env/products/<prefix>/ticket/1
... notice 'products' path prefix
URLs for global env will be just like they are now
http://host/env/ticket/1
> That means that default product must have some kind of prefix assigned
> even if it has product prefix set to NULL in DB.
>
As you can see , no . Besides global admin section and everything else
will still be needed .
> I think that the easiest way to solve this is setting default product
> prefix to some value during migration and not allowing Nulls for
> prefixes.
> Taking in mind that product prefix cannot be changed, I suggest to
> make default product prefix configurable during migration procedure,
> for example in ini file.
>
fwiw -1
--
Regards,
Olemis.
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Andrej Golcov <an...@digiverse.si>.
>>> My understanding was, based on the mailing list discussions, that we
>>> don't want tickets in global scope. That is why current implementation
>>> creates the 'default' product and migrates the tickets. I think that
>>> the 'Just Work' part is more of the UI/UX issue. I think that each
>>> ticket should be linked to a product, it's up to the UI to make it
>>> easy for the user to use environments with only one product (default
>>> one). I find tickets in global scope confusing as it's not exactly
>>> clear what they relate to.
>>>
>>> I would advocate global wikis for example, as it makes more sense.
>>
>> It's not global scope, it's default product scope which happens to have
>> no name and no prefix and no value in the related database column.
Let's look at this issue from UI point of view. AFAIR, we want to have
consistent URLs and wiki links with product prefix for all products
including default product
e.g.http://host/env/default_product_name_here/ticket/1 and not
http://host/env/ticket/1 when product prefix is None
That means that default product must have some kind of prefix assigned
even if it has product prefix set to NULL in DB.
I think that the easiest way to solve this is setting default product
prefix to some value during migration and not allowing Nulls for
prefixes.
Taking in mind that product prefix cannot be changed, I suggest to
make default product prefix configurable during migration procedure,
for example in ini file.
Regards, Andrej
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Jure Zitnik <ju...@digiverse.si>.
On 2/22/13 4:34 PM, Olemis Lang wrote:
> On 2/22/13, Branko Čibej <br...@wandisco.com> wrote:
> [...]
>> P.S.: By the way, do we test upgrades from Trac to BH? If not, why not? :)
>>
> We should .
+1
It'd be really helpful if we could get hold of a real trac database to
perform tests on. Anyone got access to a database snapshot that we could
use for testing?
Cheers,
Jure
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Olemis Lang <ol...@gmail.com>.
On 2/22/13, Branko Čibej <br...@wandisco.com> wrote:
> On 22.02.2013 11:41, Jure Zitnik wrote:
>> On 2/22/13 3:03 AM, Branko Čibej wrote:
[...]
>>> I have to say that for once I completely agree with Olemis. NULL table
>>> column, and empty UI prefix equals "it all looks exactly like it used to
>>> before the migration" and it also can't collide with any existing
>>> product names or prefixes.
>>>
>>> Furthermore, doing it this way, if a user installs Bloodhound but
>>> doesn't want to bother with product namespaces, everything will Just
>>> Work.
>>>
>> I agree with the 'Just Work' part, I don't agree with tickets in
>> global scope.
>>
>> My understanding was, based on the mailing list discussions, that we
>> don't want tickets in global scope. That is why current implementation
>> creates the 'default' product and migrates the tickets. I think that
>> the 'Just Work' part is more of the UI/UX issue. I think that each
>> ticket should be linked to a product, it's up to the UI to make it
>> easy for the user to use environments with only one product (default
>> one). I find tickets in global scope confusing as it's not exactly
>> clear what they relate to.
>>
>> I would advocate global wikis for example, as it makes more sense.
>
> It's not global scope, it's default product scope which happens to have
> no name and no prefix and no value in the related database column.
>
[...]
>
> Under the hood, this can be a completely different thing than the global
> scope.
>
jftr , I confirm this is what I had in mind since the beginning .
>
> P.S.: By the way, do we test upgrades from Trac to BH? If not, why not? :)
>
We should . That's another argument against performing MP upgrade in
EnvironmentStub.__init__ method (i.e. at the beginning of one such
test the env would be upgraded already o.O ) . In general , testing
upgrades will be easier after committing BEP-5 and refactoring
MultiproductSystem procedure accordingly . AFAICR franco included some
test cases for upgrades so it seems it all (or good part of it ;) will
come in a single package .
@franco : coluld you please confirm ?
--
Regards,
Olemis.
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Branko Čibej <br...@wandisco.com>.
On 22.02.2013 11:41, Jure Zitnik wrote:
> On 2/22/13 3:03 AM, Branko Čibej wrote:
>> On 21.02.2013 18:05, Olemis Lang wrote:
>>> On 2/21/13, Jure Zitnik <ju...@digiverse.si> wrote:
>>>> On 2/20/13 5:21 PM, Olemis Lang wrote:
>>>>> On 2/20/13, Andrej Golcov <an...@digiverse.si> wrote:
>>> [...]
>>>>>> My suggestion is to keep things simple here: if there is already
>>>>>> product named "Default', let's assign global tickets to this
>>>>>> product.
>>>>>> There should be reason why this product was called "Default" :)
>>>>>>
>>>>> -1 ... IMO we the prefix for the global environment should be an
>>>>> empty
>>>>> string (i.e. '') or NULL (/me slightly in favor of the former) . That
>>>>> will allow us to reserve special behavior for that prefix value (if
>>>>> needed) and will not clash with any other valid product prefix since
>>>>> it's a required field in create product web form (... admin command ,
>>>>> ...)
>>>>>
>>>> Just to clarify, the prefix of the 'global environment' is an empty
>>>> string (''). This will, at the moment, only be used for permissions.
>>>>
>>> Yes , understood .
>>> ;)
>>>
>>>> The 'default' prefix (or 'def') is used for a product to which all the
>>>> tickets that don't have product assigned are migrated to (during the
>>>> database upgrade process). The product itself is automatically added
>>>> during the upgrade/migration process.
>>>>
>>> That's kind of what I was meaning in my reply .
>>>
>>> 1. Consider ticket without product before migration to be
>>> tickets filed against the global environment .
>>> 2. Use gobal env just like any other product env with
>>> prefix = '' , not just permissions
>>> 3. No need to create 'default' product while on upgrade
>>>
>>> PS: In the migration process we should also replicate (i.e. in DB) or
>>> inherit product configs from a single file . I advocate for the later
>>> .
>> I have to say that for once I completely agree with Olemis. NULL table
>> column, and empty UI prefix equals "it all looks exactly like it used to
>> before the migration" and it also can't collide with any existing
>> product names or prefixes.
>>
>> Furthermore, doing it this way, if a user installs Bloodhound but
>> doesn't want to bother with product namespaces, everything will Just
>> Work.
>>
> I agree with the 'Just Work' part, I don't agree with tickets in
> global scope.
>
> My understanding was, based on the mailing list discussions, that we
> don't want tickets in global scope. That is why current implementation
> creates the 'default' product and migrates the tickets. I think that
> the 'Just Work' part is more of the UI/UX issue. I think that each
> ticket should be linked to a product, it's up to the UI to make it
> easy for the user to use environments with only one product (default
> one). I find tickets in global scope confusing as it's not exactly
> clear what they relate to.
>
> I would advocate global wikis for example, as it makes more sense.
It's not global scope, it's default product scope which happens to have
no name and no prefix and no value in the related database column.
I propose you'll have exactly three use cases:
1. User installs BH from scratch, starts using products immediately,
doesn't notice the magic default product.
2. User installs BH from scratch, eventually starts using products at
which point they move tickets from the magic default product. They,
at least initially, don't have to be aware of products at all.
3. An existing Trac user upgrades to BH (Hooray when that happens!),
they don't use products and I'm sure don't want to suddenly deal
with some meaningless "default" prefix.
Under the hood, this can be a completely different thing than the global
scope.
-- Brane
P.S.: By the way, do we test upgrades from Trac to BH? If not, why not? :)
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Jure Zitnik <ju...@digiverse.si>.
On 2/22/13 3:03 AM, Branko Čibej wrote:
> On 21.02.2013 18:05, Olemis Lang wrote:
>> On 2/21/13, Jure Zitnik <ju...@digiverse.si> wrote:
>>> On 2/20/13 5:21 PM, Olemis Lang wrote:
>>>> On 2/20/13, Andrej Golcov <an...@digiverse.si> wrote:
>> [...]
>>>>> My suggestion is to keep things simple here: if there is already
>>>>> product named "Default', let's assign global tickets to this product.
>>>>> There should be reason why this product was called "Default" :)
>>>>>
>>>> -1 ... IMO we the prefix for the global environment should be an empty
>>>> string (i.e. '') or NULL (/me slightly in favor of the former) . That
>>>> will allow us to reserve special behavior for that prefix value (if
>>>> needed) and will not clash with any other valid product prefix since
>>>> it's a required field in create product web form (... admin command ,
>>>> ...)
>>>>
>>> Just to clarify, the prefix of the 'global environment' is an empty
>>> string (''). This will, at the moment, only be used for permissions.
>>>
>> Yes , understood .
>> ;)
>>
>>> The 'default' prefix (or 'def') is used for a product to which all the
>>> tickets that don't have product assigned are migrated to (during the
>>> database upgrade process). The product itself is automatically added
>>> during the upgrade/migration process.
>>>
>> That's kind of what I was meaning in my reply .
>>
>> 1. Consider ticket without product before migration to be
>> tickets filed against the global environment .
>> 2. Use gobal env just like any other product env with
>> prefix = '' , not just permissions
>> 3. No need to create 'default' product while on upgrade
>>
>> PS: In the migration process we should also replicate (i.e. in DB) or
>> inherit product configs from a single file . I advocate for the later
>> .
> I have to say that for once I completely agree with Olemis. NULL table
> column, and empty UI prefix equals "it all looks exactly like it used to
> before the migration" and it also can't collide with any existing
> product names or prefixes.
>
> Furthermore, doing it this way, if a user installs Bloodhound but
> doesn't want to bother with product namespaces, everything will Just Work.
>
I agree with the 'Just Work' part, I don't agree with tickets in global
scope.
My understanding was, based on the mailing list discussions, that we
don't want tickets in global scope. That is why current implementation
creates the 'default' product and migrates the tickets. I think that the
'Just Work' part is more of the UI/UX issue. I think that each ticket
should be linked to a product, it's up to the UI to make it easy for the
user to use environments with only one product (default one). I find
tickets in global scope confusing as it's not exactly clear what they
relate to.
I would advocate global wikis for example, as it makes more sense.
Cheers,
Jure
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Branko Čibej <br...@wandisco.com>.
On 21.02.2013 18:05, Olemis Lang wrote:
> On 2/21/13, Jure Zitnik <ju...@digiverse.si> wrote:
>> On 2/20/13 5:21 PM, Olemis Lang wrote:
>>> On 2/20/13, Andrej Golcov <an...@digiverse.si> wrote:
> [...]
>>>> My suggestion is to keep things simple here: if there is already
>>>> product named "Default', let's assign global tickets to this product.
>>>> There should be reason why this product was called "Default" :)
>>>>
>>> -1 ... IMO we the prefix for the global environment should be an empty
>>> string (i.e. '') or NULL (/me slightly in favor of the former) . That
>>> will allow us to reserve special behavior for that prefix value (if
>>> needed) and will not clash with any other valid product prefix since
>>> it's a required field in create product web form (... admin command ,
>>> ...)
>>>
>> Just to clarify, the prefix of the 'global environment' is an empty
>> string (''). This will, at the moment, only be used for permissions.
>>
> Yes , understood .
> ;)
>
>> The 'default' prefix (or 'def') is used for a product to which all the
>> tickets that don't have product assigned are migrated to (during the
>> database upgrade process). The product itself is automatically added
>> during the upgrade/migration process.
>>
> That's kind of what I was meaning in my reply .
>
> 1. Consider ticket without product before migration to be
> tickets filed against the global environment .
> 2. Use gobal env just like any other product env with
> prefix = '' , not just permissions
> 3. No need to create 'default' product while on upgrade
>
> PS: In the migration process we should also replicate (i.e. in DB) or
> inherit product configs from a single file . I advocate for the later
> .
I have to say that for once I completely agree with Olemis. NULL table
column, and empty UI prefix equals "it all looks exactly like it used to
before the migration" and it also can't collide with any existing
product names or prefixes.
Furthermore, doing it this way, if a user installs Bloodhound but
doesn't want to bother with product namespaces, everything will Just Work.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Olemis Lang <ol...@gmail.com>.
On 2/21/13, Jure Zitnik <ju...@digiverse.si> wrote:
> On 2/20/13 5:21 PM, Olemis Lang wrote:
>> On 2/20/13, Andrej Golcov <an...@digiverse.si> wrote:
[...]
>>> My suggestion is to keep things simple here: if there is already
>>> product named "Default', let's assign global tickets to this product.
>>> There should be reason why this product was called "Default" :)
>>>
>> -1 ... IMO we the prefix for the global environment should be an empty
>> string (i.e. '') or NULL (/me slightly in favor of the former) . That
>> will allow us to reserve special behavior for that prefix value (if
>> needed) and will not clash with any other valid product prefix since
>> it's a required field in create product web form (... admin command ,
>> ...)
>>
>
> Just to clarify, the prefix of the 'global environment' is an empty
> string (''). This will, at the moment, only be used for permissions.
>
Yes , understood .
;)
> The 'default' prefix (or 'def') is used for a product to which all the
> tickets that don't have product assigned are migrated to (during the
> database upgrade process). The product itself is automatically added
> during the upgrade/migration process.
>
That's kind of what I was meaning in my reply .
1. Consider ticket without product before migration to be
tickets filed against the global environment .
2. Use gobal env just like any other product env with
prefix = '' , not just permissions
3. No need to create 'default' product while on upgrade
PS: In the migration process we should also replicate (i.e. in DB) or
inherit product configs from a single file . I advocate for the later
.
--
Regards,
Olemis.
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Jure Zitnik <ju...@digiverse.si>.
On 2/20/13 5:21 PM, Olemis Lang wrote:
> On 2/20/13, Andrej Golcov <an...@digiverse.si> wrote:
>>> 1. adds 'default' product
>>> This is the product to which all tickets that don't have product set are
>>> migrated. As there won't be any global tickets, each ticket needs to be in
>>> a
>>> product, so this is where all tickets w/o product set will end up after
>>> the
>>> upgrade. The prefix, name and description are currently set to 'default',
>>> 'Default' and 'Default product' respectively. Open question remains what
>>> happens if there's a product with the same name already defined in the
>>> database. Any suggestions?
>> My suggestion is to keep things simple here: if there is already
>> product named "Default', let's assign global tickets to this product.
>> There should be reason why this product was called "Default" :)
>>
> -1 ... IMO we the prefix for the global environment should be an empty
> string (i.e. '') or NULL (/me slightly in favor of the former) . That
> will allow us to reserve special behavior for that prefix value (if
> needed) and will not clash with any other valid product prefix since
> it's a required field in create product web form (... admin command ,
> ...)
>
Just to clarify, the prefix of the 'global environment' is an empty
string (''). This will, at the moment, only be used for permissions.
The 'default' prefix (or 'def') is used for a product to which all the
tickets that don't have product assigned are migrated to (during the
database upgrade process). The product itself is automatically added
during the upgrade/migration process.
Cheers,
Jure
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Olemis Lang <ol...@gmail.com>.
On 2/20/13, Andrej Golcov <an...@digiverse.si> wrote:
>> 1. adds 'default' product
>> This is the product to which all tickets that don't have product set are
>> migrated. As there won't be any global tickets, each ticket needs to be in
>> a
>> product, so this is where all tickets w/o product set will end up after
>> the
>> upgrade. The prefix, name and description are currently set to 'default',
>> 'Default' and 'Default product' respectively. Open question remains what
>> happens if there's a product with the same name already defined in the
>> database. Any suggestions?
>
> My suggestion is to keep things simple here: if there is already
> product named "Default', let's assign global tickets to this product.
> There should be reason why this product was called "Default" :)
>
-1 ... IMO we the prefix for the global environment should be an empty
string (i.e. '') or NULL (/me slightly in favor of the former) . That
will allow us to reserve special behavior for that prefix value (if
needed) and will not clash with any other valid product prefix since
it's a required field in create product web form (... admin command ,
...)
--
Regards,
Olemis.
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Gary Martin <ga...@wandisco.com>.
On 20/02/13 12:42, Andrej Golcov wrote:
>> 1. adds 'default' product
>> This is the product to which all tickets that don't have product set are
>> migrated. As there won't be any global tickets, each ticket needs to be in a
>> product, so this is where all tickets w/o product set will end up after the
>> upgrade. The prefix, name and description are currently set to 'default',
>> 'Default' and 'Default product' respectively. Open question remains what
>> happens if there's a product with the same name already defined in the
>> database. Any suggestions?
> My suggestion is to keep things simple here: if there is already
> product named "Default', let's assign global tickets to this product.
> There should be reason why this product was called "Default" :)
>
> Regards, Andrej
It is tempting to do this but it may not be strictly correct. Perhaps if
we also add a keyword so that it is possible to select all such tickets
and batch modify them into a different product again. Something like:
migrate<uuid>.
I might encourage a shorter prefix for the default product (I am
thinking def) though this is not so important.
It may be wise for us to reserve the default namespace to reduce the
chance of such clashes.
Cheers,
Gary
Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache
Bloodhound] #406: Database upgrade to multiproduct)
Posted by Andrej Golcov <an...@digiverse.si>.
> 1. adds 'default' product
> This is the product to which all tickets that don't have product set are
> migrated. As there won't be any global tickets, each ticket needs to be in a
> product, so this is where all tickets w/o product set will end up after the
> upgrade. The prefix, name and description are currently set to 'default',
> 'Default' and 'Default product' respectively. Open question remains what
> happens if there's a product with the same name already defined in the
> database. Any suggestions?
My suggestion is to keep things simple here: if there is already
product named "Default', let's assign global tickets to this product.
There should be reason why this product was called "Default" :)
Regards, Andrej