Thanks for the help. For some reason, though, the compute function
doesn't like when 'id' is referred to in this way and throws the
exception "KeyError: 'id'". I also looked into creating a custom
validator, which I think would be handy if I wanted to do something
more complex. But then I thought that all I'm really trying to do here
is show users a "friendly" version of the primary key that already
exists, so I chose to use the represent function:
Field('id','id',
represent=lambda id:SPAN('Q',str(id+100000),'
',A('view',_href=URL('firm_read',args=id))))
It's not a very sophisticated solution, but it seems to work without
creating the overhead of maintaining an additional key field. If
anyone sees a huge flaw in this approach, please let me know.
Regards. >Jeff
On Nov 30, 1:58 am, cjrh <caleb.hatti...@gmail.com> wrote:
> On Nov 30, 1:37 am, SaltyCow <jeff.bienkow...@gmail.com> wrote:
>
> > For example, I have a table "quote" and I would like to be able to
> > refer to a given quote as something like "Q100003". The actual primary
> > key (id) of the row for that quote may be just plain "3", but it's not
> > convenient to refer to a quote that way in emails, etc.
>
> I had to do something similar recently: auto-create a "password"-like
> key in a record (created as a sub-component of uuid.uuid4()), but only
> on record creation. The problem with compute() is that it runs every
> time a record is updated, and the dict passed to the compute()
> function does not contain the current value of the field being
> computed, so you can't monitor that for deciding whether or not to
> create a new one.
>
> OTOH, if you're always going to base your number on the PK, then the
> PK will never change and therefore compute() should be fine, because
> your compute function will always calculate the same output for a
> given record.
>
> Perhaps something like this:
>
> Field('myfield', compute=lambda d: 'Q' + str(d['id'] + 10000))
>
> (Post your code for your compute() function implementation)
>
> In the end, for my scenario, we just wrote a custom validator. I
> don't have the code handy right now, but the book description of
> validators is reasonable, so that should be enough to get you started
> if compute() is insufficient for your needs.
