You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Gary Martin <ga...@wandisco.com> on 2012/11/02 04:11:03 UTC
Re: Datamodel and data consistency
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
Re: Datamodel and data consistency
Posted by Olemis Lang <ol...@gmail.com>.
On 11/2/12, Gary Martin <ga...@wandisco.com> wrote:
> On 2 November 2012 06:42, Olemis Lang <ol...@gmail.com> wrote:
>> On 11/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>
[...]
>> > 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.
Now I recall
[...]
>> >
>> > I have ignored the issue of how information is displayed
>>
>> yes , that's what it seems .
>>
>> > so this is not
>> > really enough for to adapting other resources to use immutable keys.
>> > Any
>> > thoughts on these changes?
>> >
>>
>> so far looking good , but key + label in select controls is really
>> nice to have .
>>
>
> I was also thinking this but I think those patches will probably be a good
> enough starting point so I will commit those soon.
>
yes , of course ;)
> When I was looking at that possibility I was considering adding a
> dictionary alongside the options adjusted above in trac/trac/ticket/api.py
> to provide a mapping to what the label should be.
are you talking of field.options mapping present in select fields
> It would seem that we
> would have to override the way that such fields are pre-rendered.
afaics in order to add value + label in combobox for ticket select
field it's needed to . Target markup is rendered in Genshi template
rather than request handler (i.e. python code) which is the case for
field.rendered .
> I suppose
> that we should do that anyway as the ${field.rendered} values in the
> bh_ticket_box.html template result in links to the custom query instead of
> the dashboard style view for example.
>
IMO we could get such things done by using request filters , e.g.
using __modify_* methods in theme plugin , or maybe in a component
inside multi-product plugin .
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: Datamodel and data consistency
Posted by Gary Martin <ga...@wandisco.com>.
On 2 November 2012 06:42, Olemis Lang <ol...@gmail.com> wrote:
> On 11/1/12, Gary Martin <ga...@wandisco.com> wrote:
> > Hi,
> >
>
> :)
>
> > I'm afraid that I couldn't bring myself to wait for next week.
>
> heh !
> :)
>
> > 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:
> >
> [...]
> >
> > I have ignored the issue of how information is displayed
>
> yes , that's what it seems .
>
> > so this is not
> > really enough for to adapting other resources to use immutable keys. Any
> > thoughts on these changes?
> >
>
> so far looking good , but key + label in select controls is really
> nice to have .
>
I was also thinking this but I think those patches will probably be a good
enough starting point so I will commit those soon.
When I was looking at that possibility I was considering adding a
dictionary alongside the options adjusted above in trac/trac/ticket/api.py
to provide a mapping to what the label should be. It would seem that we
would have to override the way that such fields are pre-rendered. I suppose
that we should do that anyway as the ${field.rendered} values in the
bh_ticket_box.html template result in links to the custom query instead of
the dashboard style view for example.
Cheers,
Gary
Re: Datamodel and data consistency
Posted by Olemis Lang <ol...@gmail.com>.
On 11/1/12, Gary Martin <ga...@wandisco.com> wrote:
> Hi,
>
:)
> I'm afraid that I couldn't bring myself to wait for next week.
heh !
:)
> 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:
>
[...]
>
> I have ignored the issue of how information is displayed
yes , that's what it seems .
> so this is not
> really enough for to adapting other resources to use immutable keys. Any
> thoughts on these changes?
>
so far looking good , but key + label in select controls is really
nice to have .
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article: