Hi,
Thanks for sorting out that proposal Matevz.. a portion of the current
page is below and my thoughts on it are listed after that.
On 28/06/13 12:46, Apache Bloodhound wrote:
=== Alternative 1: Global ID + scoped ID
A new, product-scoped ID would be added to the Ticket table, the global ID
would remain the same. The scoped ID would be unique per product, and a pair of
(product-prefix, scoped-id) would form a new, unique identifier for the ticket.
Tickets can thus be referenced in two ways:
* Using the global ID, e.g. /env/ticket/42. This would function the same as
before upgrade.
* Using the product + scoped ID, e.g. /env/ticket/product/<prefix>/10
When upgrading a single product environment to a multiproduct Bloodhound, the global
IDs would equal the scoped IDs, to ease the transition. Using our previous example,
the ticket /env/ticket/42 would be upgraded to /env/ticket/product/<prefix>/42.
**Database changes**
Old schema
{{{
PRIMARY KEY: (ticket-id) -> ticket
}}}
New schema
{{{
PRIMARY KEY: (ticket-id) -> ticket
UNIQUE KEY: (product-prefix, scoped-id) -> ticket
}}}
Creating a new ticket would increment the ticket-id (same as before), and
additionally the scoped-id. In order to avoid another database table to keep
track of the scoped-id,
the scoped-id could be calculated using the SELECT MAX SQL statement.
**URL mappings**
{{{
/env/ticket/<ticket-id> -> (ticket-id) -> ticket
/env/products/<product-prefix>/ticket/<scoped-id> -> (product-prefix,
scoped-id) -> ticket
}}}
**Upgrade**
Upgrading from a single product environment would retain the global IDs. The
scoped IDs created during upgrade would be identical their global IDs.
**Import**
Importing a new product into existing multiproduct environment would work in
the following manner:
* Each ticket gets a new global ID
* The scoped IDs are retained from the imported product
**Implications**
{{{TBD}}}
=== Alternative 2: Modification of global ID
In this case the global ID would lose its role as a unique database primary
key. Instead it would be changed to being unique only per product, and the pair
of (product-prefix, global-id) would become a new database primary key.
**Database changes**
Old schema
{{{
PRIMARY KEY: (ticket-id) -> ticket
}}}
New schema
{{{
PRIMARY KEY: (product-prefix, ticket-id) -> ticket
}}}
**URL mappings**
{{{
/env/products/<product-prefix>/ticket/<ticket-id> -> (product-prefix,
ticket-id) -> ticket
}}}
**Upgrade**
Upgrading from a single product environment would remove the primary key from
the global ID column, and add a new unique primary key for the (product-prefix,
ticket-id) pair.
**Import**
Importing a new product into existing multiproduct environment would simply
create the (product-prefix, ticket-id) pair for each imported ticket.
**Implications**
{{{TBD}}}
(Potential technical/performance issues with index not being incremental, check
against supported SQL databases)
Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0010>
I have to admit that I had not considered the alternative of dropping
the existing primary key altogether.
Both schemes could probably also support a
/env/ticket/<product-prefix><scoped-id> type url if we wished so there
is nothing particular extra to separate the ideas on that basis.
If we are also taking changes of product into account, I think I would
prefer maintaining the existing primary key. I am not sure if this
aspect is covered by any other proposal but I believe that we are
expecting the ability to move tickets between products and on moving,
any old ticket links to continue to work. This would effectively mean
something like redirecting to the current product and will take the
current product and ticket permissions into account. This requires that
we maintain a list of previous references and it will also be important
to make sure that there is no accidental reuse of a previously assigned
<scoped-id> within a product. On the assumption that we use an extra
table to keep track of the synonyms, then keeping the current primary
key makes sense to me.
Does anyone spot any other issues we need to worry about?
Cheers,
Gary
