incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: Datamodel and data consistency
Date Fri, 02 Nov 2012 03:11:03 GMT
Hi,

I'm afraid that I couldn't bring myself to wait for next week. I think I 
worked out why we ended up with products using the full name. It is to 
do with the way that Trac's main ticket fields use the name field to 
specify the resources from other tables. We could of course change the 
schema to respect this convention but, as we might consider other 
changes to immutable fields, we could introduce a change like this to 
core Trac:

    Index: trac/trac/ticket/api.py
    ===================================================================
    --- trac/trac/ticket/api.py    (revision 1404839)
    +++ trac/trac/ticket/api.py    (working copy)
    @@ -165,6 +165,7 @@
              (rank, field)
              where field is a dictionary that defines:
                  * name: the field name
    +            * pk: the primary key of the field table
                  * label: the label to display, preferably wrapped with
    N_()
                  * cls: the model describing the field
              the following keys can also usefully be defined:
    @@ -344,7 +345,9 @@
              for rank, field in selects:
                  cls = field['cls']
                  name = field['name']
    -            options = [val.name for val in cls.select(self.env, db=db)]
    +            pk_field = field.get('pk', 'name')
    +            options = [getattr(val, pk_field)
    +                                for val in cls.select(self.env, db=db)]
                  if not options:
                      # Fields without possible values are treated as if
    they didn't
                      # exist


I believe that the above is an area that we are already patching to 
allow another way of playing with ticket fields. Anyway, with the above 
we can subsequently add the appropriate extra part of the specification 
and we start using a different key:

    Index: bloodhound_multiproduct/multiproduct/api.py
    ===================================================================
    --- bloodhound_multiproduct/multiproduct/api.py (revision 1404839)
    +++ bloodhound_multiproduct/multiproduct/api.py (working copy)
    @@ -122,7 +122,7 @@
          def get_select_fields(self):
              """Product select fields"""
              return [(35, {'name': 'product', 'label': N_('Product'),
    -                      'cls': Product, 'optional': True})]
    +                      'cls': Product, 'pk': 'prefix','optional':
    True})]

          def get_radio_fields(self):
              """Product radio fields"""


and any update of tickets reduces to a problem of informing that the 
event has happened which, until we consider this general problem in 
greater depth can simply be the following change:

    Index: bloodhound_multiproduct/multiproduct/model.py
    ===================================================================
    --- bloodhound_multiproduct/multiproduct/model.py (revision 1404839)
    +++ bloodhound_multiproduct/multiproduct/model.py (working copy)
    @@ -273,9 +273,8 @@
              now = datetime.now(utc)
              comment = 'Product %s renamed to %s' % (old_name, new_name)
              if old_name != new_name:
    -            for t in Product.get_tickets(self._env, old_name):
    +            for t in Product.get_tickets(self._env,
    self._data['prefix']):
                      ticket = Ticket(self._env, t['id'], db)
    -                ticket['product'] = new_name
                      ticket.save_changes(author, comment, now)

          @classmethod


I have ignored the issue of how information is displayed so this is not 
really enough for to adapting other resources to use immutable keys. Any 
thoughts on these changes?

Cheers,
     Gary


On 30/10/12 05:52, Peter Koz(elj wrote:
> Ok, I think we agree on most points. I do no see going away from Trac 
> in short term compelling either. It is just something to think about. 
> For products we have a couple of enhancements in mind; I would defer 
> the discussion until then (next week hopefully). Peter 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message